From: Rajat Garg Date: 2008-03-19T02:48:13+09:00 Subject: Re: Ruby "Speedup" hints? ------=_Part_18773_15961809.1205862502310 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Guys, Given, we are talking about optimization, an big part of it is to optimize page-download times. I am told that this can be somewhat accomplished using the following - 1. Strip spaces, tabs, CR/LF from the HTML 2. Enable HTTP Compression Is there a way in RoR w/ Mongrel to accomplish the two? Rajat On Tue, Mar 18, 2008 at 7:30 AM, Avdi Grimm wrote: > On Tue, Mar 18, 2008 at 6:43 AM, Marc Heiler > wrote: > > Personally I like such simple truths. :) > > The problem with simple truths is that often aren't simple, and almost > never stay true. There was/is a large percentage of hackers in the > C/C++ community who learned certain "simple truths" about how to make > programs go faster - and continued to use them religiously for > decades, even after the compilers had made those techniques irrelavent > or even detrimental. I believe the same has happened in Java, as > JITing and other optimizations have made a lot of assumptions about > performance moot. > > The other problem with "simple truths" is that in performance, it > really isn't true that every little bit helps. I can't tell you how > many times I've seen a design which was complicated and obfuscated by > some coder's (potentially superstitious) beliefs about certain > techniques being faster than others (e.g. "always avoid dynamic > dispatch"). Almost invariably it turns out that the real performance > gains to be made are algorithmic and/or have to do with IO, and are > orders of magnitude larger than tiny gains made by following > performance "truths" - to the point that the latter gains are lost in > the statistical noise. It's often the case that those little > rule-based optimizations only served to make the code more difficult > to refactor, and thus harder to apply the real optimizations to. > > At a time in Ruby's history when it's implementation is in flux, and > there are multiple alternate implementations coming on line, I think > it is very dangerous to start compiling "rules of thumb" or "simple > truths" about Ruby performance hacks. And when such rules are stated, > they need to be quantified with benchmarks and qualified with very > specific information about the platforms those benchmarks were > gathered on. > > ...and then you should *still* write your code to be clear and > well-factored, and put off any optimizations until after you profile. > Chances are you'll discover that your real slowdown is in IO, or in > some database interaction, not in instantiating objects. > > I saw a pertinent quote the other day: "It is easier to optimize > correct code than to correct optimized code." --Bill Harlan > > -- > Avdi > > -- Rajat Garg Ph: 206-499-9495 Add: 1314 Spring Street, #412 Seattle, WA 98104 Web: http://www.pilotoutlook.com ----------------------------------------------------------------------------------------------------- Flying is the second greatest thrill known to man. Landing is the first! ------=_Part_18773_15961809.1205862502310--