Well, considering 1) we're not running with a shell, so 'hash' isn't actually available and 2) execs are pretty expensive but hashes and stats aren't, I think it makes sense.
On Oct 12, 2009, at 10:57 PM, Rein Henrichs wrote: > > So what we are essentially doing is duplicating both `which` and > `hash`. Good times. Shouldn't be too hard. > > On Mon, Oct 12, 2009 at 10:28 PM, Luke Kanies <[email protected]> > wrote: >> >> I've asked Markus and Rein to come up with a simple mod to your >> original patch that does exactly that, and we should be able to hack >> something out. >> >> On Oct 12, 2009, at 6:27 PM, Ohad Levy wrote: >> >>> Why don't we cache the binary location? we end up querying per each >>> rpm package where is yum where is rpm and where is python. >>> >>> in my original setup, i had approx 1300 packages, each one triggered >>> 3 x which ~ 0.07 second times 1300 = 90 seconds >>> >>> it seems a trivial fix to add a hash lookup instead of searching the >>> path each time. >>> >>> Ohad >>> On Tue, Oct 13, 2009 at 2:15 AM, Luke Kanies <[email protected]> >>> wrote: >>> >>> On Oct 12, 2009, at 11:13 AM, Brice Figureau wrote: >>> >>>> >>>> On 12/10/09 20:03, Luke Kanies wrote: >>>>> On Oct 12, 2009, at 10:52 AM, Paul Nasrat wrote: >>>>> >>>>>> 2009/10/12 Brice Figureau <[email protected]>: >>>>>>> +1 for this patch on top of the previous one, >>>>>>> >>>>>>> Isn't there any spec tests for this method? >>>>>>> If there aren't maybe it would be the good time to add some. >>>>>>> James, Luke: that'd be great if we could have this for 0.25.1, >>>>>>> because >>>>>>> this is a performance regression (even though only Ohad noticed >>> it, >>>>>>> seems only his servers have a damn-"slow" 'which') especially >>>>>>> for >>>>>>> yum/rpm users. >>>>>> It's probably worth doing similar in facter as well, it's cleaner >>>>>> and >>>>>> more portable to search the path. >>>>> >>>>> And for the record, I believe the numbers involved were around >>> 0.07s >>>>> per resource (instead of averaging 0.00s), so "damn slow" here >>>>> is a >>>>> bit relative. >>>> >>>> When we bisected the issue at Puppet Camp, we saw that all the >>> package >>>> installation went from 1s to 8s. >>>> That's damn slow to me :-) >>>> His bug reports reports even more slowdowns, but I think he changed >>>> his >>>> packages so that he installs much less packages (ie meta-packages). >>> >>> Ah; the numbers I remember from the beginning were much different, >>> so >>> I guess I'm remembering wrong. Yeah, that's bad. >>> >>>> >>>>> I think the reasons Ohad caught it are 1) he's got a bunch of >>>>> resources and 2) he pays close attention to how long things take >>> and >>>>> where the time goes. I expect others are being hit by this and >>> just >>>>> don't realize it. >>>> >>>> Yes, most people won't care what happens on the client as long as >>>> it >>>> doesn't produce load on the master. Or maybe people don't look to >>>> client >>>> metrics. Or people have fast 'which' or don't use yum/rpm :-) >>> >>> >>> Yep. Yum, it sure is slow. :/ >>> >>> -- >>> Should I say "I believe in physics", or "I know that physics is >>> true"? >>> -- Ludwig Wittgenstein, On Certainty, 602. >>> --------------------------------------------------------------------- >>> Luke Kanies | http://reductivelabs.com | http://madstop.com >>> >>> >>> >>> >>> >>>> >> >> >> -- >> In theory, there is no difference between theory and practice; in >> practice, there is. -- Chuck Reid >> --------------------------------------------------------------------- >> Luke Kanies | http://reductivelabs.com | http://madstop.com >> >> >>> >> > > > > -- > Rein Henrichs > http://reductivelabs.com > > > -- Brand's Shortcut: The only way to predict the future is to make sure it stays exactly the same as the present. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
