This happens on 10.04.2 LTS (x86_64) linux 2.6.32-30-generic with OO 3.2.0 as well.

Its not just OO Base.. general OO Basic macro execution in OO Calc spreadsheets execute 4 to 5 times slower than with previous JRE (22).

As a test case - creating a JDBC database connection "datasource1" (be sure to install necessary java class files for particular databse) and use the following macro in a Calc spreadsheet:

REM  *****  BASIC  *****

Global Pipe_connectedDatabase As Boolean	' Are we connected to the database?
Global Pipe_dConn as Variant
Global Pipe_dStat as Variant

function pipe (f_s as string) as variant
    on error goto err_h

	Dim dataType As Long		' What type of data was returned by the database?
	dim url as String
	dim driver as String
	dim dBase as Variant
	dim oDB as Variant
	dim oManager as Variant
	dim oMetaData as Variant
	dim connArgs(0) As New com.sun.star.beans.PropertyValue
	' These declarations below are for casting data types around in BASIC
	Dim tmpDouble As Double		' Temporary holder for a double datatype, for inserting into Any
	Dim tmpString As String		' Temporary holder for a string datatype, for inserting into Any 

	' Actual database query
	if Pipe_connectedDatabase = false then
        dBase = createUnoService("com.sun.star.sdb.DatabaseContext")
        oDB = dBase.getByName("datasource1")
        url = oDB.URL
        driver = oDB.Settings.JavaDriverClass
        oManager = createUnoService ("com.sun.star.sdbc.DriverManager")
        connArgs(0).name = "JavaDriverClass"
        connArgs(0).value = driver
        Pipe_dConn = oManager.getConnectionWithInfo (url, connArgs)
        Pipe_connectedDatabase = true
        Pipe_dStat = Pipe_dConn.createStatement()
    end if
	oSet = Pipe_dStat.executeQuery (f_s) 
	

	' Datatype casting logic
	if oSet.next () then
		' Get a LONG representation of the type of data that was returned by the
		' database
		dataType = oSet.getMetaData().getColumnType(1)
		Select Case dataType

			Case com.sun.star.sdbc.DataType.CHAR
				tmpString = RTrim(oSet.getString(1))
				ret_val = tmpString

			Case com.sun.star.sdbc.DataType.SMALLINT
				tmpDouble = oSet.getDouble(1)
				ret_val = tmpDouble

			Case com.sun.star.sdbc.DataType.INTEGER
				tmpDouble = oSet.getDouble(1)
				ret_val = tmpDouble

			Case com.sun.star.sdbc.DataType.DECIMAL
				tmpDouble = oSet.getDouble(1)
				ret_val = tmpDouble

			Case com.sun.star.sdbc.DataType.VARCHAR
				tmpString = RTrim(oSet.getString(1))
				ret_val = tmpString

			Case com.sun.star.sdbc.DataType.DATE
				tmpString = Trim(oSet.getString(1))
				ret_val = tmpString

			Case Else
				' Insert unknown types as string
				tmpString = RTrim(oSet.getString(1))
				ret_val = tmpString

		End Select
	
	else
	  ret_val = "##NULL##"
	end if
	pipe = ret_val
	exit function
err_h:

	if Pipe_connectedDatabase = true then
		Pipe_dConn.close()
		Pipe_connectedDatabase = false
	endif

	pipe = "##ERROR##"
	exit function
end function


To test it..  in a cell enter:  =pipe("select count(*) from sometable")  

(sometable being the name of actual database table)

This should return the number of rows and insert it in the cell as a value (If you only get ##ERROR## - suspect jdbc connectivity issue/java class path issue).

This alone doesn't reveal performance issue.. BUT.. copy and paste this to 1000 cells.. and compare the performance with 22 and 24.