I think this might also be a case of a phenomena i see frequently especially in chess and searching for vulnerabilities. If someone gives you a chess puzzle and tells you to find the solution its often much easier to do than finding tactics in your own game. i think if you gave a developer who had some understanding of CSS and asked them what the performance problem was they would be able to identify the `matches?` method as the culprit. but if you wrote this code or reviewed this code and you didn't know there was a problem then i think identifying the `matches?` method as a problem would be more difficult. i've been thinking it might even be free to just assume there is a tactic in a chess position or a problem in some piece of code and use that to change your frame of mind to spot these issues. but i don't think this works out in practice because you might be able to change your frame of mind but this comes at a cost of spending more time and focus on the task.
How we made a Ruby method 200x faster
41–48 of 48 posts
Re: How we made a Ruby method 200x faster
#42I don't understand "how we made X in Ruby/Python Y% faster" posts. It is of course possible to optimize functions in any language, and often worthwhile to do, but if you're going to spend a lot of engineering resources on it, then can I introduce you to my friends C++ and Rust?
I agree
Re: How we made a Ruby method 200x faster
#43I've flamegraph-debugged JS code from time to time, and it usually feels a lot more of a craft and "educated guesses" than the vast majority of programming things I do. I usually only get down to it when there's an actual perf problem so YMMV, but I'm curious, do I do JS flamegraph debugging wrong, or is it something like this for everyone? - 20% of the times you get lucky and find a very easy win that speeds up thin…
I do low level systems programming, so pretty different from JS-land, but I feel the techniques you should apply when doing optimization generally apply at any level/language. 0) algorithmic improvement. Obvious shit like do a quick sort instead of bubble sort (assuming N > 64, or whatever), not doing unnecessary work in a hot loop, etc 1) reduce memory footprint. The slowest part of your program is almost always jus…
> Web applications are probably always memory bound
IO bound and particularly network bound code is common too. The first fix I'd try with network bound code is to either eliminate the network call (local cache? turn a microservice into a library?) or to batch operations.
> Last step is to multithread it if it needs even more juice
In web app land, this is fraught with peril if you're doing it on the server, because it means your code is now competing for n times the resources. Often it's better for one request to take a long time if it means it's using a more predictable amount of memory, not causing other requests to time out, not exhausting your DB connection pool, etc.
I imagine that systems programming is similar in some ways and that's why multithreading is the last resort, just mentioning it because it's easy to shoot oneself in the foot with parallelism.
Re: How we made a Ruby method 200x faster
#44I don't understand "how we made X in Ruby/Python Y% faster" posts. It is of course possible to optimize functions in any language, and often worthwhile to do, but if you're going to spend a lot of engineering resources on it, then can I introduce you to my friends C++ and Rust?
Part of the point of using "friendlier" languages is to make it easier (or perhaps feasible) to express better algorithms. Porting existing code to a very different language is not fun, either. No matter how many "engineering resources" you're planning to spend, there are more and less efficient ways of doing so. Very often, "use C or Rust" (or other such languages) is simply not one of the more efficient ways. If it consistently were, other languages wouldn't be nearly as popular as they are.
Re: How we made a Ruby method 200x faster
#45I think this might also be a case of a phenomena i see frequently especially in chess and searching for vulnerabilities. If someone gives you a chess puzzle and tells you to find the solution its often much easier to do than finding tactics in your own game. i think if you gave a developer who had some understanding of CSS and asked them what the performance problem was they would be able to identify the `matches?` m…
They used their metrics to confirm the regression, and flame graphs to see where the cpu was spending its time. That’s performance tuning basics and anyone who is familiar with profiling code should be able to find the slow spots.
I’ve been doing Ruby for a decade and the matches? method immediately stood out to me. Methods doing any kind of comparison/regex or looping usually end up causing problems. Nokigiri was walking a tree of child nodes and doing a string comparison. I’ve seen people write themselves similar problems with methods like any? includes?, excludes?, etc. Par for the course.
Re: How we made a Ruby method 200x faster
#46Is campsite related at all to 37 signals or basecamp? I feel like it being a ruby shop and being named campsite is a little uninspired if not.
Re: How we made a Ruby method 200x faster
#47Earlier quoted context omitted.
I do low level systems programming, so pretty different from JS-land, but I feel the techniques you should apply when doing optimization generally apply at any level/language. 0) algorithmic improvement. Obvious shit like do a quick sort instead of bubble sort (assuming N > 64, or whatever), not doing unnecessary work in a hot loop, etc 1) reduce memory footprint. The slowest part of your program is almost always jus…
> Web applications are probably always memory bound IO bound and particularly network bound code is common too. The first fix I'd try with network bound code is to either eliminate the network call (local cache? turn a microservice into a library?) or to batch operations. > Last step is to multithread it if it needs even more juice In web app land, this is fraught with peril if you're doing it on the server, because…
Some good points, thanks for the insight :)
Yeah, when I multithread something I pretty much assume that I can hog the whole machine for the time slice the job is going to be running. Said another way, I assume there will be a small number of large jobs running on the machine at any given time, which attempt to saturate the machine. Typically dispatched to a core-locked threadpool of some sort.
Definitely agree with the sentiment that multithreading is hard. Especially when trying to get every last drop..
Re: How we made a Ruby method 200x faster
#48I don't understand "how we made X in Ruby/Python Y% faster" posts. It is of course possible to optimize functions in any language, and often worthwhile to do, but if you're going to spend a lot of engineering resources on it, then can I introduce you to my friends C++ and Rust?
Part of the point of using "friendlier" languages is to make it easier (or perhaps feasible ) to express better algorithms. Porting existing code to a very different language is not fun, either. No matter how many "engineering resources" you're planning to spend, there are more and less efficient ways of doing so. Very often, "use C or Rust" (or other such languages) is simply not one of the more efficient ways. If i…
Expressing a better algorithm, or getting optimizations for free is clear win.
What’s not clear is why these languages should expose more low level performance tuning - such as multithreaded python. This removes invariants which make the language friendly, so that experts can squeeze out a constant speed up factor which is already an order of magnitude off from the proper tool.