Specifically see RE (tilly) 6 (bench): File reading efficiency and other surly remarks. Your speed claim can only
be made for the specific setup you tested. If your code
will need to run on multiple machines then the optimization
is almost certainly wasted effort. If performance does not
turn out to be a problem, it is likewise counterproductive
to have sacrificed maintainability for this.
In short, the fact that this might be faster is
very good to know for the times that you need to
squeeze performance out on one specific platform. But
don't apply such optimizations until you know that you
need to, and don't apply this one until you have
benchmarked it against your target setup.
A few general notes on optimization. Given the overhead
of an interpreted language, shorter code is likely to be
faster. With well modularized code you retain the ability
to recognize algorithm improvements later - which is
almost always a better win. Worrying about debuggability
up front speeds development and gives more time to worry
after the fact about performance. And readable code is
easier to understand and optimize.
Which all boils down to, don't prematurely optimize. Aim
for good solid code that you are able to modify after you
have enough of your project up and running that you can
identify where the bottlenecks really turned out to be. | 