Live data from Hacker News

Speeding up Rails startup time

rhnh.net

1–10 of 33 posts

Re: Speeding up Rails startup time

#4
Couple things:

* Wow, an O(n^2) require algo. I guess this really drives home that we shouldn't make basic assumptions about the quality of the libs we use without actually looking at them. Great catch.

* For all of you waiting for this to be pulled into Ruby master. Why not just patch your copy in the meantime?

Re: Speeding up Rails startup time

#6
post #5

Seriously? Ruby made it to 1.9.3 with this shitty of a module loader? Is the language written by a bunch of ass clowns or what?

He reduced the example in the post to the core of the issue, which is the time complexity O(n) for each load (thus O(n^2) overall), and his replacing the existing data structure with what seems (I didn't look at the patch for very long) like a hash[1] which should be O(1) for each load (O(n) overall). A tradeoff of speed for some additional memory.

There is quite a bit going on in module loading. I think reducing it to 'ass clowns' is a bit unwarranted.

[1]: publicly exposed as an array, but a hash internally for actual loading and checking to see if loaded already.

edit: fixed bigO notation

Re: Speeding up Rails startup time

#8
Given the roots in Perl, which has the %INC hash, it's surprising that Ruby started with an array for loaded modules. Can anyone shed some light on this design decision? Surely there was a reason at some point -- and maybe there still is.
Post reply on HN