The title kinda glossed over the fact that they started out with working, fast code, and then broke it. Sure, their fix was faster than their most broken version, but it's less impressive than starting with slow code and improving it.
How we made a Ruby method 200x faster
11–20 of 48 posts
Re: How we made a Ruby method 200x faster
#12I'm curious how the case/when version performs. Unlike the author, I don't think that is any smellier than the list/map solution they've come up with.
"we improved performance with a simple trick! (rollback our changes)"
Re: How we made a Ruby method 200x faster
#13This should have been obvious before the fact to anyone who understands how CSS selectors work in browsers.
As in, they are matched right-to-left, which implies that a selector like ”p a” first selects all the nodes, and for each of them, it then traverses up the DOM tree until it encounters a
node (selector matches) or the root node (selector doesn’t match).
That said, the traversing shouldn’t happen for plain tag selectors like ”h1”. There must be something wrong with the library they used.
Re: How we made a Ruby method 200x faster
#14Earlier quoted context omitted.
A bigger question for me would be why the handlers don’t register themselves. It should be a very small amount of meta-programmation, and would avoid having to repeat the handlers to register them.
Self-registration is usually an anti-pattern in my experience because it introduces globals. Sometimes you can't avoid it, but if you only have a few things to register it's usually better to just list them explicitly.
> Self-registration is usually an anti-pattern in my experience because it introduces globals.
You mean unlike explicit registration introducing the HANDLERS_BY_NODE_NAMES global?
Re: How we made a Ruby method 200x faster
#15The title implies they fixed a method in Ruby itself which would have been a lot more interesting than this article.
Re: How we made a Ruby method 200x faster
#16The waterfall of end statements in Ruby reminds me of pascal. Seems verbose.
Nobody ever likes my suggestion to write them all on one line. I thought it was neat - the length of the word `end` makes it line up perfectly with 4-space indentation:
class HtmlTransform
class Code Re: How we made a Ruby method 200x faster
#17Earlier quoted context omitted.
A bigger question for me would be why the handlers don’t register themselves. It should be a very small amount of meta-programmation, and would avoid having to repeat the handlers to register them.
Self-registration is usually an anti-pattern in my experience because it introduces globals. Sometimes you can't avoid it, but if you only have a few things to register it's usually better to just list them explicitly.
Self-registration has a lot of problems.
Global state, like you say - you can't merge two apps that use the same registration mechanism but use incompatible registered sets.
Lack of discoverability in maintenance - it's a kind of COME FROM but for data.
A barried to optimization: it's not clear what will break when you remove a dependency, and you have to eagerly run all initializers everywhere - if you try to be clever and lazy, you have to pick and choose, and you're back to explicit but indirect registration.
Initialization order problems: if you have code you run during init which depends on the stuff you register at init time, you're going to have to manually manage your initialization in error-prone ways. Adding or removing dependencies may change initialization order.
Re: How we made a Ruby method 200x faster
#18The waterfall of end statements in Ruby reminds me of pascal. Seems verbose.
Nobody ever likes my suggestion to write them all on one line. I thought it was neat - the length of the word `end` makes it line up perfectly with 4-space indentation: class HtmlTransform class Code
I think it's pretty easy to see why people would dislike it, with each on their own line and indented, it's very easy to track what ends where. With this version, not so much, if you're e.g. five nests deep and then see three end statements on one line.
Re: How we made a Ruby method 200x faster
#19Earlier quoted context omitted.
Nobody ever likes my suggestion to write them all on one line. I thought it was neat - the length of the word `end` makes it line up perfectly with 4-space indentation: class HtmlTransform class Code
I think it's pretty easy to see why people would dislike it, with each on their own line and indented, it's very easy to track what ends where. With this version, not so much, if you're e.g. five nests deep and then see three end statements on one line.
I think this is fine - I don't see why having the `end`s on separate lines would make it easier to understand:
if ...
if ...
if ...
if ...
if ...
x = 1
end end end
y = 2
end endRe: How we made a Ruby method 200x faster
#20Earlier quoted context omitted.
Self-registration is usually an anti-pattern in my experience because it introduces globals. Sometimes you can't avoid it, but if you only have a few things to register it's usually better to just list them explicitly.
> Self-registration is usually an anti-pattern in my experience because it introduces globals. You mean unlike explicit registration introducing the HANDLERS_BY_NODE_NAMES global?
Well I guess it isn't quite as simple as I implied.
The handlers don't know anything about HtmlHandler, so you are free to make OtherHtmlHandler or whatever. The dependency direction is correct, whereas with self-registration your handlers now depend on some single unique global registry. HANDLERS_BY_NODE_NAMES doesn't affect any other code that might interact with the handlers (tests is normally the big one).
barrkei gave some very good reasons to avoid self-registration.