3 ms·

Really? I've no idea what that product is but I hardly think it's a "thinking" problem, more a managing expectation or shit requirements gathering problem. If i

Really? I've no idea what that product is but I hardly think it's a "thinking" problem, more a managing expectation or shit requirements gathering problem. If it was necessary to search in a certian way over a certain size in a certain time, you could make the appropriate trade off. Sounds like you just wanted to bitch out about a particular product pal.

adrianN 10y ago
I admit I like bitching about slow software. But if you don't put speed as one of your top requirements, over time your software will become slower and slower. Having one operation that takes 100ms instead of 10ms is fine until two years later when somebody else who doesn't bother to read your code uses it to implement something that now takes one second instead of 100ms, which is incidentally used a hundred times to complete some query that now takes minutes instead of seconds. Now imagine you're a company like IBM or SAP that works on the same code base for decades and the cruft keeps layering and layering until even finding out which part of the code needs to be tuned becomes too expensive to explain to your customers. There is http://accidentallyquadratic.tumblr.com http://accidentallyquadratic.tumblr.com with a nice collection of "it was fast enough at the time" code.
- mnkmnk 10y ago
  Why would it be difficult to profile and find the bottleneck after a few decades? It should actually be even easier with better profiling tools and practices.
  - adrianN 10y ago
    Uniformly shitty code is hard to profile. See for example what Chandler has to say about writing good code https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs
- to3m 10y ago
  There's an explanatory post there that in particular is very much worth reading: http://accidentallyquadratic.tumblr.com/post/113840433022/why-accidentally-quadratic http://accidentallyquadratic.tumblr.com/post/113840433022/wh...

adrianN 10y ago

I admit I like bitching about slow software. But if you don't put speed as one of your top requirements, over time your software will become slower and slower. Having one operation that takes 100ms instead of 10ms is fine until two years later when somebody else who doesn't bother to read your code uses it to implement something that now takes one second instead of 100ms, which is incidentally used a hundred times to complete some query that now takes minutes instead of seconds. Now imagine you're a company like IBM or SAP that works on the same code base for decades and the cruft keeps layering and layering until even finding out which part of the code needs to be tuned becomes too expensive to explain to your customers. There is http://accidentallyquadratic.tumblr.com http://accidentallyquadratic.tumblr.com with a nice collection of "it was fast enough at the time" code.

mnkmnk 10y ago
Why would it be difficult to profile and find the bottleneck after a few decades? It should actually be even easier with better profiling tools and practices.
- adrianN 10y ago
  Uniformly shitty code is hard to profile. See for example what Chandler has to say about writing good code https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs
to3m 10y ago
There's an explanatory post there that in particular is very much worth reading: http://accidentallyquadratic.tumblr.com/post/113840433022/why-accidentally-quadratic http://accidentallyquadratic.tumblr.com/post/113840433022/wh...