Guys,
There is an important performance issue with Database.allocateObjectId().
Over time it becomes slower and slower.
I'm running again my favorite benchmark (see below) and it does not get to
a stable point, throughput goes down constantly even on a single thread.
Sampling shows that it is a Database.allocateObjectId() method degrades.
Since this method is called for query intermediate result temp tables as
well, I think overall query performance can depend on it pretty much.
I should say that my goal is to make the code below run as fast as possible
and scale well in multithreaded environment and I see many places for
improvement, but this issue needs to be discussed first.
May be this is an id leak, but I'm not sure. The idea of returning ids back
itself is quite complex and error prone, it would be much more simple and
fast to have AtomicLong for this purpose and don't care about overflows and
stuff like that. Even my cheap mobile has 1g of RAM, why care about
additional 4 bytes per DB object? On modern hardware it makes no sense at
all.
Thoughts?
@Benchmark
@Warmup(iterations = 150, time = 3, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 20, time = 3, timeUnit = TimeUnit.SECONDS)
@Threads(1)
public void testMethod() throws SQLException {
Connection c = connect.get();
try (Statement s = c.createStatement()) {
s.executeUpdate("create local temporary table t(id int)");
s.executeUpdate("drop table t");
}
}
Sergi
--
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.
