On 2007-10-30 19:54:00 +0100, MenTaLguY <mental / rydia.net> said:

> On Wed, 31 Oct 2007 03:25:03 +0900, Josselin <josselin / wanadoo.fr> wrote:
>> thanks a lot..  when trying to get DRY,  I just wonder if it helps in
>> performance ..
>> in both cases we perform 6 IF..
> 
> I'd be more concerned with the multiple calls to #distance_to in the
> original.
> 
> If there could be a lot of zoom levels (~50 or more), then it might
> be worthwhile to replace the linear search with a binary search (giving
> you only log2(N) tests to do rather than the full N), but with the small
> number of zoom levels available in Google Maps, the extra complexity
> likely isn't worth it.
yes, wich is not the case with GoogleMaps ;-))
> 
> I also wouldn't worry too much about performance unless this particular
> piece of code is a measurable hot spot in your performance profile.
> Otherwise, it's easy to tie yourself into knots worrying about the
> performance of things which cannot have a significant impact on execution
> time.
> 
> In the beginning, just focus on clarity and maintainability (which is what
> DRY really speaks to):  you'll often get a little performance improvement
> and shorter code as side benefits without having to worry about either
> directly.
> 
> -mental

thanks very useful advice...it's true that optimizing DB access 
performances is my first objective,
 I am trying then to look over some 're-du-plicated' lines or big loops 
to avoid lengthy source code (as you say clarity and maintainability..  
in this particular case, maybe the 6 lines are better for clarity to 
anybody looking at the code later....  ;-)


joss