Hello,
I was profiling a performance issue in our own software, when I noticed an
excessive amount of time being spent
in org.h2.util.DateTimeUtils.getTimeTry(), even if the benchmark selected
only one timestamp column with dozens of other columns:
http://i.imgur.com/KJdXEWB.png
I am a bit confused by the algorithm, and I suspect there are a couple of
issues here. The org.h2.value.ValueTimestamp type stores nanos and
dateValue, which are then converted to a JDBC java.sql.Timestamp through a
Calendar. Why? Wouldn't it be sufficient to just call new Timestamp(time)?
The TimeZone that is applied in DateTimeUtils.convertDateValueToTimestamp()
is the default one, so I don't see the benefit of passing through Calendar.
Things get worse when looking at giveTimeTry():
private static long getTimeTry(boolean lenient, TimeZone tz,
int year, int month, int day, int hour, int minute, int second,
int millis) {
Calendar c;
if (tz == null) {
c = getCalendar();
} else {
c = Calendar.getInstance(tz);
}
synchronized (c) {
c.clear();
c.setLenient(lenient);
setCalendarFields(c, year, month, day, hour, minute, second,
millis);
return c.getTime().getTime();
}
}
This method (possibly) synchronizes on a global static calendar object. If
this happens in a high throughput scenario, pretty much every database
session will then need to synchronize on this single object.
What are your thoughts on this?
Cheers
Lukas
PS: I was using 1.4.177 for this benchmark.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/d/optout.
