Hi,
Because of the lack of feedback, I decided to start hacking blindly ;)
Generating the Loaders on demand broke for an unknown reason, so what
I do now is to pad the batch-load request with non-existant primary
keys up to the next larger batch-size and distribute the batch-sizes a
bit more unif
On May 4, 2012, at 7:33 PM, Steve Ebersole wrote:
> Touche ;)
>
> Ok I'll just chaulk it up to that then.
>
> Overall do you think that is an issue with Jenkins? Or with the JBoss setup?
>
>
not sure, but we may improve this.
the slaves used by Jenkins can be labeled, and all hibernate jobs
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
Touche ;)
Ok I'll just chaulk it up to that then.
Overall do you think that is an issue with Jenkins? Or with the JBoss setup?
On May 3, 2012 11:15 PM, "Strong Liu" wrote:
>
> On May 4, 2012, at 3:45 AM, Steve Ebersole wrote:
>
> But I killed it and #243 started *immediately*
>
>
> well, you al
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
12 matches
Mail list logo
