5 ms·

I think this was already quoted in somewhere, but, its the best advice; "The key to making programs fast is to make them do practically nothing."

by chukye 10y ago

reacweb 10y ago
Yes and we underestimate how often this kind of rule can apply. To have fast network, reduces network utilisation (for example using cache). To have fast database, reduce number of queries (for example using more complex queries). To have fast memory allocation, avoid dynamic memory or preallocate...
mozumder 10y ago
Also useful: "If you want to make a fast program, use a slow computer."
- laumars 10y ago
  Not really necessary in most cases. There's enough profiling tools available that can give response times in fractions of a second and in many cases you can add repetition to inflate the few processes that are still too small to measure. These will give you far more meaningful figures about the performance of your code than anecdotal evidence using a slow PC as a benchmark.
  - dr_zoidberg 10y ago
    I agree with both of you. Once I optimized a major Python project to avoid some bad disk access patterns. Nobody noticed them because everyone was using SSDs and those patterns didn't hurt (too much) performance on those, but I was running on an HDD and I had run times of hours (vs a couple of minutes for everyone else). But my optimizations were guided by the profiler and a (more or less) correct analysis of the results.
  - adrianN 10y ago
    Developers care more about performance if it's slow on their computers too.
    - kochthesecond 10y ago
      Haha, this is true. Yet i still need to have as fast build and feedback as possible when I'm doing work.
      - StillBored 10y ago
        Which is one of a hundred reasons why the machine you write the code on, the machine you build it on, and the machine you test it on, should be three different machines (actually probably more than that because your test environment should be more varied than a single OS/environment).
        laumars 10y ago
        If we really want to adhere to best working practices, then it should be a separate team performing the tests based on the same specifications that the developers used to write the code (ie the testing team wouldn't perform tests based on the developers specifications but rather the project owners specs to mitigate the risk of the developers misunderstanding the specs). However that requires a level of process that is either too costly, or too rigid for many IT companies to follow.
- CaptSpify 10y ago
  I used to work at a place that had an intentionally slow dsl line, and a ~5 year old, beat up pc to test their code on. If it worked there, it would work for their customers. I wish more places would try this. Sure, your app works in downtown SF, but if your customer is in Nowheresville, AL, you should probably spend more time optimizing.
  - sotojuan 10y ago
    I wish more web developers would test their sites on 3G connections with Australian latency :-)
    - sliverstorm 10y ago
      The difference between 3G & 4G both in speed and latency is profound, and nobody seems to design with 3G in mind, so I find from a data standpoint 3G is practically worse than nothing these days. All of your apps will say "I have data access!" and send a million requests for tens of megabytes, which will never finish, melting your battery as it waits on timeouts and completely choking the access you do have preventing you from doing anything useful.
    - drakonandor 10y ago
      Why encourage technology lag and bad ISP behavior?
      - CaptSpify 10y ago
        Because that's the lazy answer
      - takeda 10y ago
        Because programmers are lazy. Why making program faster when it works fine on their top of the line desktop machines?
blowski 10y ago
That's what separates good and bad teams (or individual developers): the wisdom of how to make a program that does the bare minimum while actually solving the problem.
- nxzero 10y ago
  "Make things as simple as possible, but not simpler."
  - setra 10y ago
    He is saying make the program spend less time computing. Thats what he means by not looking at every byte. The way he does that is by using more complicated algorithms. It's not simple.
    - nxzero 10y ago
      Quote is often credited to Einstein; being "simple" does not mean something is not complex, it means that there's no unnecessary complexity; being "too simple" means necessary complexity was remove. Basically means only do exactly what's required, nothing more, nothing less.
zamalek 10y ago
This also works if you are aiming for stable software - I can't find the quote or who to attribute it to: > The only bug-free line of code is the line of code that is never written.
- Waterluvian 10y ago
  This is why I find myself writing fewer bugs when I'm writing Python. I write less and have less to mess up.
  - galdosdi 10y ago
    This is actually why I find myself writing fewer bugs when I'm writing Java than Python. Thanks to static typing, I don't need to endlessly repeat myself writing and updating boilerplate unit tests and boilerplate documentation (and inevitably messing up) I've heard about PEP484 and hope it catches on, but unfortunately it's for python3 and a lot of people are still stuck on python2 for many reasons.
- tombert 10y ago
  cough That's kind of why I feel like Haskell is a superior language to most others.
  - zamalek 10y ago
    Too true. I read an account of some product being ported to F# (from C#) a few years back. The line count was substantially decreased (at least one order of magnitude if I'm remembering correctly) with a correlated decrease in defects. I can't find the original post, but there are plenty of supporting testimonials[1]. [1]: http://fsharp.org/testimonials/ http://fsharp.org/testimonials/
    - tombert 10y ago
      Yeah, as someone who gets to use F# fairly regularly, actually, it's a substantial improvement in the LOC department compared to Java or C#. I don't find it quite as reliable as something like Haskell (do to the fact that you don't have to be explicit about side-effects), but it's definitely better than most languages.

I think this was already quoted in somewhere, but, its the best advice; "The key to making programs fast is to make them do practically nothing."

by chukye 10y ago

I think this was already quoted in somewhere, but, its the best advice; "The key to making programs fast is to make them do practically nothing."

reacweb 10y ago

Yes and we underestimate how often this kind of rule can apply. To have fast network, reduces network utilisation (for example using cache). To have fast database, reduce number of queries (for example using more complex queries). To have fast memory allocation, avoid dynamic memory or preallocate...

mozumder 10y ago

Also useful: "If you want to make a fast program, use a slow computer."

laumars 10y ago
Not really necessary in most cases. There's enough profiling tools available that can give response times in fractions of a second and in many cases you can add repetition to inflate the few processes that are still too small to measure. These will give you far more meaningful figures about the performance of your code than anecdotal evidence using a slow PC as a benchmark.
- dr_zoidberg 10y ago
  I agree with both of you. Once I optimized a major Python project to avoid some bad disk access patterns. Nobody noticed them because everyone was using SSDs and those patterns didn't hurt (too much) performance on those, but I was running on an HDD and I had run times of hours (vs a couple of minutes for everyone else). But my optimizations were guided by the profiler and a (more or less) correct analysis of the results.
- adrianN 10y ago
  Developers care more about performance if it's slow on their computers too.
  - kochthesecond 10y ago
    Haha, this is true. Yet i still need to have as fast build and feedback as possible when I'm doing work.
    - StillBored 10y ago
      Which is one of a hundred reasons why the machine you write the code on, the machine you build it on, and the machine you test it on, should be three different machines (actually probably more than that because your test environment should be more varied than a single OS/environment).
      - laumars 10y ago
        If we really want to adhere to best working practices, then it should be a separate team performing the tests based on the same specifications that the developers used to write the code (ie the testing team wouldn't perform tests based on the developers specifications but rather the project owners specs to mitigate the risk of the developers misunderstanding the specs). However that requires a level of process that is either too costly, or too rigid for many IT companies to follow.
CaptSpify 10y ago
I used to work at a place that had an intentionally slow dsl line, and a ~5 year old, beat up pc to test their code on. If it worked there, it would work for their customers. I wish more places would try this. Sure, your app works in downtown SF, but if your customer is in Nowheresville, AL, you should probably spend more time optimizing.
- sotojuan 10y ago
  I wish more web developers would test their sites on 3G connections with Australian latency :-)
  - sliverstorm 10y ago
    The difference between 3G & 4G both in speed and latency is profound, and nobody seems to design with 3G in mind, so I find from a data standpoint 3G is practically worse than nothing these days. All of your apps will say "I have data access!" and send a million requests for tens of megabytes, which will never finish, melting your battery as it waits on timeouts and completely choking the access you do have preventing you from doing anything useful.
  - drakonandor 10y ago
    Why encourage technology lag and bad ISP behavior?
    - CaptSpify 10y ago
      Because that's the lazy answer
    - takeda 10y ago
      Because programmers are lazy. Why making program faster when it works fine on their top of the line desktop machines?

blowski 10y ago

That's what separates good and bad teams (or individual developers): the wisdom of how to make a program that does the bare minimum while actually solving the problem.

nxzero 10y ago
"Make things as simple as possible, but not simpler."
- setra 10y ago
  He is saying make the program spend less time computing. Thats what he means by not looking at every byte. The way he does that is by using more complicated algorithms. It's not simple.
  - nxzero 10y ago
    Quote is often credited to Einstein; being "simple" does not mean something is not complex, it means that there's no unnecessary complexity; being "too simple" means necessary complexity was remove. Basically means only do exactly what's required, nothing more, nothing less.

zamalek 10y ago

This also works if you are aiming for stable software - I can't find the quote or who to attribute it to: > The only bug-free line of code is the line of code that is never written.

Waterluvian 10y ago
This is why I find myself writing fewer bugs when I'm writing Python. I write less and have less to mess up.
- galdosdi 10y ago
  This is actually why I find myself writing fewer bugs when I'm writing Java than Python. Thanks to static typing, I don't need to endlessly repeat myself writing and updating boilerplate unit tests and boilerplate documentation (and inevitably messing up) I've heard about PEP484 and hope it catches on, but unfortunately it's for python3 and a lot of people are still stuck on python2 for many reasons.
tombert 10y ago
cough That's kind of why I feel like Haskell is a superior language to most others.
- zamalek 10y ago
  Too true. I read an account of some product being ported to F# (from C#) a few years back. The line count was substantially decreased (at least one order of magnitude if I'm remembering correctly) with a correlated decrease in defects. I can't find the original post, but there are plenty of supporting testimonials[1]. [1]: http://fsharp.org/testimonials/ http://fsharp.org/testimonials/
  - tombert 10y ago
    Yeah, as someone who gets to use F# fairly regularly, actually, it's a substantial improvement in the LOC department compared to Java or C#. I don't find it quite as reliable as something like Haskell (do to the fact that you don't have to be explicit about side-effects), but it's definitely better than most languages.