Kamesh Jayachandran writes:
> Peter Lundblad wrote:
> > I am not sure I find this way "better". Sure, it does avoid a slight
> > allocation out of a pool. OTOH, when one reads this cod,e one has to
> > think "hey, where does this hash table come from, is it considered
> > read-only, and am I sure no caller up the call chain doesn't pass it
> > to multiple threads at a time?" Is this microoptimization really worth
> >
> Out of 5 instances where this patch changes, 3 are straight forward
> local hash tables. And no new threads could have access to this local
> pointers.
I am not disputing that fact. My point is that when reviewing this code,
you have to make sure that's the case, and what does it actually buy us?
> We already do this at 'determine_merges_performed' like
> 'apr_hash_first(NULL, notify_b->skipped_paths)'.
Sorry for not paying attention then, but I'll also call this a premature
optimization. I'd rather like us be consistent here since we almost are.
Show me that it can make a real difference, and I'll of course reconsider;)
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 22 13:51:48 2007