Next time I grab a heap dump from one of our prod boxes I can poke
around in the org.hibernate classes a bit and let you know what YourKit
says if you guys want :)
-Eric
On 5/4/12 7:14 AM, Steve Ebersole wrote:
> Apparently this did not go through to the list the first time, sorry...
>
> Comple
Not this one :(
This library argument is just not relevant to how persisters store
internal state, which is really all I am talking about. And in terms of
the SPI, if we opt to expose this change, is happening in a major rev;
so again not relevant.
As for perf issues OGM uncovered in ORM... F
Apparently this did not go through to the list the first time, sorry...
Completely agree.
I focused on perf in my last comment but I dont think memory is all that
much different. The declaration of all that state already has to be
accounted for in its current "flattened" parallel-array represe
On May 4, 2012, at 1:51 PM, Steve Ebersole wrote:
> As for perf issues OGM uncovered in ORM... First, none of those involved
> anything close to the discussion here; they dealt mostly with small things
> (like hashCode caching) that became big because of size of scale. Second,
> thats actuall
+1!
Agreed to be the a good library in the area it's critical to be user
friendly: good APIs, good docs and good quality, but to be the best
out there it's not enough: users demand top efficiency and are
extremely annoyed when they find a performance issue in our code, to
the point they will advert
Yes, but we can't blindly go for the nicer approach: we are a library and hence
used by many.
Look at the bottleneck we found on Hibernate ORM due to the change of magnitude
Hibernate OGM involved. Look at the perf issues we found in OGM itself just
because I used the builder pattern for some o
Even taking the risk of pouring oil onto the fire, I think a simpler data
structure wins in most cases over
the parallel arrays. It is much harder to use the latter and easier to make
mistakes which leads to more
bugs and higher maintenance costs.
As Sanne is saying performance questions are tr
tricky subject.
I'm confident that there are many cases in which we should have used
arrays rather than maps, especially for temporary objects which aren't
short lived enough (an HashMap living in the scope of a single method
is going to be cheap). We should have either objects allocated for
very l
Performance I don't know, you are probably right. But memory wise, that could
be way different.
Even ignoring the overhead of the object + pointer in memory, the alignment of
boolean or other small objects would make a significant impact.
Of course if we are talking about 20 values, we should no
I seriously doubt the performance cost of 20 'parallel arrays' versus 1
array of Objects holding those 20 values is anything but negligible at
best.
On Thu 03 May 2012 11:04:30 AM CDT, Emmanuel Bernard wrote:
> Sorry I could not assist the meeting live but reviewed the logs and had some
> rema
10 matches
Mail list logo
