<html><body>
<p><tt>>>>"Consider the end-to-end process. If the portion of the process you want to spend money/time on went to zero, what percentage improvement will I see?" This perspective makes it clear that what they want to do is not worth doing. They grasp, that overall, what they want to do has only a negligible impact on the end-to-end process.<<<</tt><br>
<br>
<tt>Absolutely, this is the way to go. I dislike doing optimizations without an effective and measurable gain.</tt><br>
<br>
<tt>We added this optimization when we did a project for a big consulting compagny (now aquired by IBM, any idea? :-) ). It appeared that the HTML pages showed up 2 to 3 times faster, just because of this.</tt><br>
<br>
<tt>I'm convinced that optimizations should be done not only on theorical basis, but also on practical ones, experienced on real world projects. Saying "The cost of all <br>
in-memory manipulation is trivial compared to the cost of input and output" must be proved by concrete measures. And this is especially wrong when the input/output time tend to zero and no parsing is required, as in our case.</tt><br>
<br>
<tt>I remember when we changed the LinkedList to ArrayList, years ago. Lot of people were just thinking that a linked list was faster. I then sent some OptimizeIt results to prove that ArrayList speeded up the library but also saved memory.</tt><br>
<tt>This is also what I did with the factory, measuring the effective gain.</tt><br>
<br>
<tt>Phil.</tt></body></html>