These are chat archives for ManageIQ/manageiq/performance

30th
Mar 2016
Joe Rafaniello
@jrafanie
Mar 30 2016 01:12
FYI, @kbrock @dmetzger57, it looks like fast_gettext is open to lazy loading the mo files for the translations in test/dev: grosser/fast_gettext#75 and it looks like a redhatter on the foreman team did something similar: theforeman/hammer-cli#198... do you have a tracker for TODO items? Should I open a gh issue? Or is dumping ideas into gitter ok? The gist is loading all of the mo files for all translations in test/dev or even prod could get very expensive (load time, memory consumption) as we add more and more translations
Keenan Brock
@kbrock
Mar 30 2016 01:13
@jrafanie what is the desire? hammer that stuff away?
Joe Rafaniello
@jrafanie
Mar 30 2016 01:13
:clap:
Jason Frey
@Fryguy
Mar 30 2016 01:15
I don't think we need a GH issue if it makes it upstream, unless your rang to
want to track it for yourself
Joe Rafaniello
@jrafanie
Mar 30 2016 01:16
I know I'm not working on it now so I don't want to lose it ;-)
Keenan Brock
@kbrock
Mar 30 2016 01:16
so the hope is fast_gettext will fix it and we will reap benefit?
Rather than jumping through hoops like foreman folks?
Joe Rafaniello
@jrafanie
Mar 30 2016 01:16
well, it sounds like they're open to a PR
Jason Frey
@Fryguy
Mar 30 2016 01:17
Yeah, take Foreman's LazyMoFile class and push it upstream
Joe Rafaniello
@jrafanie
Mar 30 2016 01:18
I want to do it, just don't have the cycles
it annoys me to no end
Keenan Brock
@kbrock
Mar 30 2016 01:26
and how did you find this stuff? @jrafanie ;)
Joe Rafaniello
@jrafanie
Mar 30 2016 01:27
I didn't think it made sense to load 50 translation files in dev/test so I looked at fast_gettext_rails first, then to the fast_gettext to see if there was an open issue ;-)
Keenan Brock
@kbrock
Mar 30 2016 01:28
logical
Keenan Brock
@kbrock
Mar 30 2016 21:03
@Fryguy I noticed that indexes are on resource_id, resource_type (general rule of thumb) - but I would have expected that putting it on resource_type, resource_id would have been better. was there some logic behind this?
Also noticed that we specify :btree and the :name - which I didn't think either were necessary
Matthew Draper
@matthewd
Mar 30 2016 21:13
Explicit index names are because the Rails default changed between 3.2 and 4.x: without the explicit value, migrations could create differently-named indexes (and thus different looking DBs) depending on which Rails version ran them
Keenan Brock
@kbrock
Mar 30 2016 21:14
thanks
Keenan Brock
@kbrock
Mar 30 2016 23:11
@matthewd you have ideas for ideas for https://github.com/ManageIq/manageiq/blob/master/app/models/metric_rollup.rb#L12-L16
That actually uses the columns_hash at class load time.
Is there a rails "define this field when columns are fetched" kind of behavior? Or maybe a simplified method_missing type approach? (remember @tenderlove spoke about define_method and method missing a number of years back - 5+?)
I was able to remove the references everywhere else
Matthew Draper
@matthewd
Mar 30 2016 23:23
def self.load_schema!; … your stuff here…; super; end, maybe?
Depends whether calling columns_hash will end up recursing back to load_schema, which would be Bad
Keenan Brock
@kbrock
Mar 30 2016 23:24
lol
is it ok to just plain monkey patch a class in an initializer
thought you were suposed to use a active support load routine to do that saftely
Matthew Draper
@matthewd
Mar 30 2016 23:25
Otherwise, you could do it after the super call… but then you wouldn't want to use virtual_column because that clears the very cache you just populated
Keenan Brock
@kbrock
Mar 30 2016 23:25
if they class reload and stuff, it breaks
Matthew Draper
@matthewd
Mar 30 2016 23:26
Correct. Don't monkey-patch autoloaded stuff.
If you must, you can use to_prepare… but don't. ;)