Обсуждение: Some more profiling hotspots

As per my previous email, the biggest JDBC driver
bottleneck is in:

-------------------------------------------------
org.postgresql.core.Encoding.decode
[new string creation in various places]
-------------------------------------------------

But here are some more profiled hotspots (note, the
line numbers
may *not* be accurate but the method names *are*
accurate):

org.postgresql.core.PGStream.ReceiveString (line:
1487)
org.postgresql.core.v3.QueryExecutorImpl.receiveFields
(line: 1364)
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getFixedString

org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTime
(line: 2049)
org.postgresql.jdbc2.TimestampUtils.toTime (line: 404)
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getXXX...


Best regards,
--j

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

j.random.programmer wrote:
> As per my previous email, the biggest JDBC driver
> bottleneck is in:

What is the testcase you're using?

-O

Oliver:

> j.random.programmer wrote:
> > As per my previous email, the biggest JDBC driver
> > bottleneck is in:
>

Just some  PreparedStatements to get data from the
databa,
run under JProfiler. JProfiler really rocks (I have no
financial interest
in the company, just a very satisfied user, its waaay
better than
JProbe/OptimizeIt used to be, many years ago).

At the core, the code simply uses connections are
pooled. I
consistently get very high usage, via new string
creation in the:

    org.postgresql.core.Encoding.decode

method.

If you don't have JProfiler yourself, I'd be happy to
profile any other
code you want to send my way.

Of course, I should try to grok the driver code and
post a patch but
that's probably beyond my ability...     :-)

Best regards,
--j



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

j.random.programmer wrote:
> Oliver:
>
>> j.random.programmer wrote:
>>> As per my previous email, the biggest JDBC driver
>>> bottleneck is in:
>
> Just some  PreparedStatements to get data from the
> databa,

Can you be more specific? A profile is no use if we don't know what the
workload was. Are the queries moving lots of data around? Are you using
metadata at all? etc etc.

-O

j.random.programmer wrote:
> consistently get very high usage, via new string
> creation in the:
>
>     org.postgresql.core.Encoding.decode
>
> method.

Doesn't look like like there is much room for optimization. The jvm may
spend a lot of time in this method because it is called often.


public String decode(byte[] encodedString, int offset, int length)
throws IOException
{
    if (encoding == null)
        return new String(encodedString, offset, length);

    return new String(encodedString, offset, length, encoding);    }

public String decode(byte[] encodedString) throws IOException
{
    return decode(encodedString, 0, encodedString.length);
}


Till

Oliver:

Thanks for the quick followup !

I'm actually using a framework that I've developed,
which does
the standard O/R mapping from tables to java objects.

So if I have a table foo:

I automatically get:
  table_foo.java and
  table_fooMgr.java

The above is generated using via the framework
(internally using
JDBC meta data). This part is NOT profiled. Once the
classes
are generated, JDBC meta data is never used again.

So to actually run the profiled code, I say:
----------------------------------------------
Connection con = ....get connection....
for (int n = 0; n < 100000; n++)
  {
  table_foo prototype = new table_foo();
  prototype.set_column_a(1);
  prototype.set_column_b("2");
  List rows = table_fooMgr.getUsing(con, proto);
  }
-----------------------------------------

That's it in a nutshell. The actual stuff going over
the wire that
the getUsing(...) method above calls is a prepared
statement and
the query looks like:

SELECT column_a, column_b [...] from table_foo
WHERE column_a=1 and column_b='2' [...]

That prepared statement (and the JDBC driver code that
is called) is
what is really profiled under the covers. I know this
is still not very detailed. The only data fetched from
the database is via the
above query.

Unfortunately, it's hard to post the entire code
because there are dependencies on the framework etc.

I'm going to post a link to this framework (it's
really very cool, O/R, a
page templating language, many other cool things) when
I have it up
on the web. In the meantime, forgive my posting
incomplete info...but
at least this will give you a hint as to what's
getting profiled.

I'm running all this on:
  JDK 1.5.0_06
  postgres 8.1
  postgres 8.2dev-503 JDBC 3 driver.

Best regards,
--j



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com