3 ms·
I've always thought there were 2 types of things that could be optimized: 1. Things that need to be "cleaned up". 2. Things that never should have been writte
by edw519 16y ago
I've always thought there were 2 types of things that could be optimized:
1. Things that need to be "cleaned up".
2. Things that never should have been written in the first place.
Simple example of Type 1: You rush to get something up and running, and in your first code review, you find the exact same code multiple times. So you write a function, parameterize a few variables, tighten it up, and reference it all over the place. Cool.
Simple example of Type 2: You have an SQL SELECT inside an iteration. At 500 iterations it runs smoothly. At 50,000 iterations, it becomes non-functional. Your only hope to scale this thing is to rethink the whole process to run with one SQL SELECT (and maybe a database redesign) outside the iteration. You basically have to start over. What were you thinking?
You need to trust your "process" that Type 1 things will rise to the surface in due time, thus avoiding premature optimization.
For Type 2 things, there is no such thing as "premature optimization". They need to be designed and written properly in the first place.
- Locke1689 16y agoYour example 2 is actually not as ridiculous as you state. For example, the following lines are from Market Watch Frame 1 in the TPC-E benchmark. open stock_list do until(stock_list.end_of_cursor) { fetch from stock_list cursor into symbol select new_price = LT_PRICE from LAST_TRADE where LT_S_SYMB = symbol We spend a lot of time trying to optimize these types of OLTP transactions and in certain cases you may be better off using this structure than a more esoteric, less optimized construct. Edit: I guess I should mention that the cursor in there is going to hurt. Just an example -- don't always actually do that and rely on us to speed up your transaction.
- tom_b 16y agoAs a gradually reforming software performance engineer, I spent a lot of time discovering type 2 items off in enterprise software. I think your background is similar. What is more amazing, is I think a number of projects I worked on as a performance tester had no developer on staff or team for a large enterprise software product who could make a determination that the type 2 error had occurred. I think this was mainly the result of having only background in a specific tech stack (I saw lots of low-hanging opportunities for doing set operations in the database rather than pulling stuff in with J2EE or even in db code written in an imperative style . . . <shudders when thinking of T-SQL in legacy product> ).
- jakevoytko 16y agoIt's too easy to wrongly believe you have a good Type 2 optimization. One might be tempted to replace their language's brute-force string searching with Boyer-Moore... after all, it obviously uses fewer comparisons. But brute force is usually fast enough in regular text for non-search intensive applications - it can find the last sentence of Moby Dick in 5ms on my laptop. And most of us aren't searching through Moby Dick each time a webpage is loaded. I hope. Optimizations should really only be made at the Type 1 level. I'm all for cleaning up and refactoring code. Your Type 2 example is really a Type 1 problem in disguise, since it's not the simplest way to do it! If you want to do a Type 2 change, measure it and prove to yourself it's worthy of your time. Just solve the problem simply and cleanly and hope for the best. The huge performance hogs are almost never where you expect to see them anyways.