On Wed, Sep 28, 2011 at 4:29 AM, Alan Post <alanp...@sunflowerriver.org> wrote: > > I don't have enough data to say that it matters in this case, but in > principle it surely does.
"In theory, theory and practice are the same. In practice, they're different." The problem here specifically is the lack of data. Why even bother with a change like this without benchmark results to prove it's worth it (preferably tested across all the variety of platforms Chicken compiles on, with wildly differing branch prediction features)? The proper way to optimize is: 1) DON'T! Just write an application. If it's too slow for your purposes, then move on to 2) Profile. Find out where all the time is being spent. There's no point in optimizing something if it's not a significant factor in you performance. 3) Of the code sections you've determined the most time is being spent in, choose the one with the best estimated speedup-to-effort ratio. You should have an intuition that the code in question can be improved, either algorithmically (potential huge speedup) or by tuning (smaller speedup, usually uglier code, but may be less effort). Making this choice is something of an art, but is completely impossible without 2. 4) Write benchmarks that isolate what you want to optimize. Measure how fast the current solution is, if possible compared to alternative implementations or equivalent tasks in other languages. 5) If you don't already have a test suite, write one now that verifies the code used in the benchmark. It's too easy to write an optimized version of something that performs better initially, but worse once you fix the bugs in it. 6) Try one or more optimizations, and measure them compared to the result in 4 once they've passed the tests in 5. Iterate as often as you have time/ideas. 7) Of the best results in 6, determine if the speedup they introduce is worth the complexity they introduce. Keep in mind the maintenance cost will persist long term, and be shared by other people who want to work on the code. 8) Document what you tried regardless so people don't waste the same effort again! Include a one-line comment in the code itself with a link to more info if needed, e.g. ;; The following is a little ugly, but performs best in ;; practice - see benchmarks/widget-hack.scm. 9) Send a patch to the list with the benchmarks and tests as proof that the optimization is worth it. If you've come this far, the maintainers will almost certainly accept it. -- Alex _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users