4 ms·

You're not wrong, but despite being complicated, this codegen is less than 200 lines of comment heavy code. This might have been a very light lift in comparison

You're not wrong, but despite being complicated, this codegen is less than 200 lines of comment heavy code. This might have been a very light lift in comparison to whatever fundamental architectural changes would be necessary to solve the problem at its root.

bravura 2y ago
Didn't your mother teach you not to prematurely optimize? You'll grow hair on your hands.
- willseth 2y ago
  What's premature? 50% of their runtime was spent in this one function call
  - necovek 2y ago
    If you have scalability problems, getting something to be twice as quick is unlikely to solve it: you are usually looking for at least an order of magnitude, if not two or more orders of magnitude, or ideally an exponential improvement. But, for some of the basic stuff in Python, you do get that with external C-based modules.
    - willseth 2y ago
      The code he optimized sped up at least 1-2 orders of magnitude
      - necovek 2y ago
        > ...where it sped up a production stack by nearly 2x This is a quote from the article. 2x is not even in the ballpark of a single order of magnitude (~ 10x), let alone more than that.
poulsbohemian 2y ago
Totally understood, but I've just never found anything that was this simple in any real-world production code. That's not a criticism, it's just sharing a perspective. The only time I can think of that came even close to this was about 20 years ago I worked on a project where for nearly every remote call they were also invoking a function that made an expensive auth call. Yes, the "problem" was in a single function, but there wasn't anything explicitly wrong with the function, rather the overall auth pattern.
- jlarocco 2y ago
  I agree. The project I work on right now has some major performance issues, and I'd LOVE if it were just a few bad inner loops that we could re-write. Instead it's more like death by a million cuts with the end result being a performance nightmare. Honestly I think the "avoid premature optimization" quote has done more harm than good. Too many people think it means "don't think about performance at all until it's a problem," but by then it's too late and actually a lot of problems combined.
- mhuffman 2y ago
  You never inherited a project that opened a db, made a single db call, and closed it again in a loop to process an entire table? I'm jealous! Some people get so used to bad architecture that if you fix it they become suspicious. "What? That call normally takes 10 mins. to run and it just completed in 2 seconds? We need to test this, something must be wrong here!"

bravura 2y ago

Didn't your mother teach you not to prematurely optimize? You'll grow hair on your hands.

willseth 2y ago
What's premature? 50% of their runtime was spent in this one function call
- necovek 2y ago
  If you have scalability problems, getting something to be twice as quick is unlikely to solve it: you are usually looking for at least an order of magnitude, if not two or more orders of magnitude, or ideally an exponential improvement. But, for some of the basic stuff in Python, you do get that with external C-based modules.
  - willseth 2y ago
    The code he optimized sped up at least 1-2 orders of magnitude
    - necovek 2y ago
      > ...where it sped up a production stack by nearly 2x This is a quote from the article. 2x is not even in the ballpark of a single order of magnitude (~ 10x), let alone more than that.

poulsbohemian 2y ago

Totally understood, but I've just never found anything that was this simple in any real-world production code. That's not a criticism, it's just sharing a perspective. The only time I can think of that came even close to this was about 20 years ago I worked on a project where for nearly every remote call they were also invoking a function that made an expensive auth call. Yes, the "problem" was in a single function, but there wasn't anything explicitly wrong with the function, rather the overall auth pattern.

jlarocco 2y ago
I agree. The project I work on right now has some major performance issues, and I'd LOVE if it were just a few bad inner loops that we could re-write. Instead it's more like death by a million cuts with the end result being a performance nightmare. Honestly I think the "avoid premature optimization" quote has done more harm than good. Too many people think it means "don't think about performance at all until it's a problem," but by then it's too late and actually a lot of problems combined.
mhuffman 2y ago
You never inherited a project that opened a db, made a single db call, and closed it again in a loop to process an entire table? I'm jealous! Some people get so used to bad architecture that if you fix it they become suspicious. "What? That call normally takes 10 mins. to run and it just completed in 2 seconds? We need to test this, something must be wrong here!"