These are chat archives for ManageIQ/manageiq/performance

3rd
Dec 2016
Keenan Brock
@kbrock
Dec 03 2016 02:32
@jrafanie I may have forwarded this interview to you before, but it does look like that organization of heaps based upon age. This reminds me of how java organizes their heaps with the different generational heaps. (interview was from ruby weekly a few weeks back)
Keenan Brock
@kbrock
Dec 03 2016 02:40
it also reminds me of how the ibm jvm is able to use the classes as shared memory not per process. looks like jruby has a similar shared class cache.
the jvm sure has a lot of neat stuff. looking forward to many of those features joining c-ruby
Jason Frey
@Fryguy
Dec 03 2016 02:45
have you seen @tenderlove's latest heap compaction work?
Keenan Brock
@kbrock
Dec 03 2016 02:45
no
what is up?
Keenan Brock
@kbrock
Dec 03 2016 02:46
the second graph is bigger. more memory? :trollface:
looking nice
Jason Frey
@Fryguy
Dec 03 2016 02:47
not sure but that might also include separating heaps by age
Keenan Brock
@kbrock
Dec 03 2016 02:47
ooh, you think he did that?
nice
Jason Frey
@Fryguy
Dec 03 2016 02:47
I know he wants to
Keenan Brock
@kbrock
Dec 03 2016 02:48
yea, he was the one who mentioned that is what he was doing
yea
Jason Frey
@Fryguy
Dec 03 2016 02:48
and movable objects is an important step in that direciton
Keenan Brock
@kbrock
Dec 03 2016 02:50
yea
but it did sound like he was thinking that you can assume that class definitions are long term off the bat
no movable objects needed
I know it is not infalliable but.. it is close
yes, rails does bust the class cache a bunch with the method missing optimizations of defining the methods. but with stuff like find_by() instead of find_by_* - those are reducing
specifically to avoid the class loader cache performance issues
yes, the graph you are showing there are definitely movable objects. that is very slick
Keenan Brock
@kbrock
Dec 03 2016 03:05
oh @Fryguy I am totally missing your statement [here] - could you help me see when you get a chance?
happy weekend
Keenan Brock
@kbrock
Dec 03 2016 03:39
@Fryguy also re stefankroes/ancestry#296 -- I think I want to push hard getting the ancestry column parsing into a single source. So we can introduce multiple strategies. I really want arrays in there so we can see if that would make things like what @NickLaMuro is doing (string concatination of the ancestry string field so we can join into ancestrys in pure sql) in the db w/o funkyness
curiously, I had basically done the same thing in another PR but decided it would be easier to fix ancestry. Alas, I never finished.
Nick has suggested yet again that it may be better to get it done (in a non "perfect" way) rather than just add it to the already long someday/maybe list
perfection is procrastination and is the enimy of shipping
Jason Frey
@Fryguy
Dec 03 2016 03:45
Weird I thought we merged that already :/
Keenan Brock
@kbrock
Dec 03 2016 04:06
think we trimmed it back

@Fryguy off hand, how do I know if I'm loading the database in schema load?
at class definition I want to mixin a different module.
I had used connection - mistake. so we moved it to inside the lambda (not what I want)
It seems to be working for using connection_config but I'm not positive that I didn't introduce db load at definition time again.

Ideas how to ensure I didn't just do taboo again?

Keenan Brock
@kbrock
Dec 03 2016 04:13
oh well - will try again tomorrow