[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: The no goto religion
From:       "Joshua J. Berry" <des () condordes ! net>
Date:       2007-08-04 16:34:41
Message-ID: 200708040934.49788.des () condordes ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 30 July 2007 03:45:42 James Richard Tyrer wrote:
> Profiling is used for macro-optimization, it has no place in peephole
> optimization.

In my experience, your point about micro-optimizations (or "peephole 
optimizations", or whatever you want to call them) is simply wrong.

I've run into a number of situations in my work projects where I'll perform 
some "obvious" micro-optimization (such as the one you are suggesting) only 
to have the profile numbers become significantly *worse*.  (Unfortunately I 
can't give a specific example -- employer confidentiality and whatnot.)

So Knuth's point about premature optimization definitely applies here -- 
profile *first*, to make sure the problem's where you think it is.  Only 
after you've profiled should you even begin to discuss how to fix it.  
Then, once you've come up with a solution, profile *again* to test your 
solution and make sure it actually works.

Otherwise, you have no idea what is going on.

Really, this is standard software engineering practice -- you have to 
identify and confirm the problem before you fix it (profiling beforehand), 
fix it, then test to make sure you actually did (profiling afterward).

You wouldn't close a bug without having tested to make sure your patch 
works, would you?  So why would you discount the importance of profiling 
when performing optimizations?


-- 
Joshua J. Berry

"I haven't lost my mind -- it's backed up on tape somewhere."
    -- /usr/games/fortune

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]