So you're testing in-memory only? Hmmm, then your results are kind of what I expect. If you're testing in-memory, you are testing the cost of our parsing and storage management layers. Which have become more expensive as we have become more sophisticated.
If you really care about in-memory performance, then the right answer is ConcurrentHashMap, not H2 :-) So what we are really interested in, is how good we are at dealing with the limited bandwidth available when we talking to a disk storage subsystem. That said, if we can find any ways to shave off overhead in the in-memory case, that will be still be a good thing, On Tue, 30 Apr 2019 at 07:05, Christian MICHON <[email protected]> wrote: > I'll do that and keep you posted > > -- > 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 https://groups.google.com/group/h2-database. > For more options, visit https://groups.google.com/d/optout. > -- 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 https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
