3 ms·

This is something that's been bothering me for the last decade (okay, more.). Every time I've articulated it in the past I've been dismissed, but it really is k

This is something that's been bothering me for the last decade (okay, more.). Every time I've articulated it in the past I've been dismissed, but it really is key to good performance. iirc, the GNOME folks once did some benchmarking and found they could get huge speedups by trimming a few bytes here and there from the gnome libraries. I hope more people take the time to consider the implications of code bloat. I'm not asking for hand written assembler, but just a little bit of thought here and there can produce huge improvements. EDIT: This is also why ssd's are so exciting. Yes the're not perfect yet, but they promise to (all but) eliminate disk latency within the next few years.

rarestblog 17y ago
Too true. "We should forget about small efficiencies, say about 97% of the time" Donald Knuth We often forget about the rest 3% too.
- lallysingh 17y ago
  It's a shame that profiling/performance/cache utilization analysis tools aren't nearly as common/standardized as the rest of a developer's toolbox.
  - mojuba 17y ago
    Valgrind/cachegrind are fairly common in the UNIX/C world. Our company uses it as part of the automated build/test run.
    - lallysingh 17y ago
      Sadly they only support: X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux Which doesn't help me :-(
joeyo 17y ago
Side anecdote to your SSD note: I have a bit of code that steps through a binary file made up of blocks that are of a known size, in an arbitrary order, and come in N different flavors and save them into N output files, one for each flavor. It actually does much more too, but lets pretend this is the only operation. The simple way to do this is to step sequentially through the file and load everything into memory in N different structures and then save your files. But the problem is that sometimes you don't have enough memory to do that, so you have to loop through the file N times, loading a type, saving it, clearing memory and repeating. Since that seems very inefficient, so I thought I'd be clever and on the first pass through the file, load one of the flavors and also save file pointers to all the other blocks so that each subsequent pass could be done more quickly by seeking to the exact black that I needed to load. Long story short, on regular hard drives, thanks to optimized sequential reads it can actually be faster to just do the dumb thing and loop through the file N times than seek though it randomly.

rarestblog 17y ago

Too true. "We should forget about small efficiencies, say about 97% of the time" Donald Knuth We often forget about the rest 3% too.

lallysingh 17y ago
It's a shame that profiling/performance/cache utilization analysis tools aren't nearly as common/standardized as the rest of a developer's toolbox.
- mojuba 17y ago
  Valgrind/cachegrind are fairly common in the UNIX/C world. Our company uses it as part of the automated build/test run.
  - lallysingh 17y ago
    Sadly they only support: X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux Which doesn't help me :-(

joeyo 17y ago

Side anecdote to your SSD note: I have a bit of code that steps through a binary file made up of blocks that are of a known size, in an arbitrary order, and come in N different flavors and save them into N output files, one for each flavor. It actually does much more too, but lets pretend this is the only operation. The simple way to do this is to step sequentially through the file and load everything into memory in N different structures and then save your files. But the problem is that sometimes you don't have enough memory to do that, so you have to loop through the file N times, loading a type, saving it, clearing memory and repeating. Since that seems very inefficient, so I thought I'd be clever and on the first pass through the file, load one of the flavors and also save file pointers to all the other blocks so that each subsequent pass could be done more quickly by seeking to the exact black that I needed to load. Long story short, on regular hard drives, thanks to optimized sequential reads it can actually be faster to just do the dumb thing and loop through the file N times than seek though it randomly.