These are chat archives for ManageIQ/manageiq/performance

5th
May 2016
Keenan Brock
@kbrock
May 05 2016 13:35
@jrafanie I added MANY micro commits to ManageIQ/manageiq#8429 - hope that reads better for you
added comments changed to +9/−45 :(
Joe Rafaniello
@jrafanie
May 05 2016 13:53
@kbrock Sorry, I didn't explain better. I didn't mean that you were doing too much in a single commit, it was that the message was vague.
for example, I'd prefer the to swap the subject /body in this commit: https://github.com/ManageIQ/manageiq/pull/8429/commits/8e215b4b962cfa4764a04793bbc3d3ce46b301c0
this makes more sense as a commit message to me: separate the vm selection from the mapping to vms than metric::targets - flat_map.select
I can see what you're doing in the commit, I want to know why when using git log/blame
Keenan Brock
@kbrock
May 05 2016 15:10

this makes more sense as a commit message to me: separate the vm selection from the mapping to vms
@jrafanie

feel like it also needs context 'cap&u' tricky with the limited number of characters. You have a better title for that commit? I can mimic that commit for others.

@jrafanie and how many commits do you want to see. The feedback I always get is "how did you get there from here" So cutting it up into chunks that git diff shows a good story means cutting it up pretty small
Joe Rafaniello
@jrafanie
May 05 2016 15:37
Yeah, it's not always easy to express a complete explanation in the subject of a commit but if I can't write a subject without using AND, it sometimes is an indication the commit is doing too much
the important thing is to keep unrelated changes separate
Jason Frey
@Fryguy
May 05 2016 18:51
@jrafanie Thought this might interest you...the thought came to me after Xavier's talk about how Rails boots...
02:48:17 ~/dev/manageiq (master) (2.2.4) ✓ time be rails r 1
** master - vmdb_development on localhost
** Using session_store: ActionDispatch::Session::MemCacheStore
bundle exec rails r 1  9.44s user 1.79s system 99% cpu 11.278 total

02:48:32 ~/dev/manageiq (master) (2.2.4) ✓ time bin/rails r 1
** master - vmdb_development on localhost
** Using session_store: ActionDispatch::Session::MemCacheStore
bin/rails r 1  7.50s user 1.62s system 99% cpu 9.162 total
user: 9.44s -> 7.50s ...total: 11.278s -> 9.162s (instant 20% speedup! :trollface: )
Keenan Brock
@kbrock
May 05 2016 18:53
what is the difference?
Chris Arcand
@chrisarcand
May 05 2016 18:53
binstubs are a bit quicker.
Keenan Brock
@kbrock
May 05 2016 18:53
aah
be the rails
Joe Rafaniello
@jrafanie
May 05 2016 18:55
Can you do them multiple times each?
the first call to rails r is always slower
Jason Frey
@Fryguy
May 05 2016 18:55
the binstubs load gems differently that bundle exec
Joe Rafaniello
@jrafanie
May 05 2016 18:56
yeah, I'm just saying that benchmark is too small of a sample size
Joe Rafaniello
@jrafanie
May 05 2016 19:07
I am excited about this: grosser/fast_gettext#79
working on lazy po since we use po files for our message catalogs. tl;dr lazy load message catalogs so we don't spend 1-2 seconds loading japanese, chinese, dutch in rails console/runner, running tests, migrating the db, etc.
Jason Frey
@Fryguy
May 05 2016 19:37
Yes I did it a number of times before copy pasting here
Keenan Brock
@kbrock
May 05 2016 20:02
I've heard similar reports around bin stubs
remember it mad a BIG difference for jruby
because you are essentially kicking off ruby 2 times for bundle exec
the first time to get the environment setup, and the 2nd time to actualy run it (but this time with a different GEM_PATH)