25 messages in org.ibiblio.lists.xom-interest[XOM-interest] Three cosmetic patches
FromSent OnAttachments
Wolfgang HoschekFeb 9, 2004 6:42 pm 
Elliotte Rusty HaroldFeb 10, 2004 9:25 am 
Wolfgang HoschekFeb 10, 2004 3:23 pm 
jco...@reutershealth.comFeb 10, 2004 3:48 pm 
Elliotte Rusty HaroldFeb 11, 2004 1:21 pm 
Wolfgang HoschekFeb 11, 2004 1:24 pm 
jco...@reutershealth.comFeb 11, 2004 2:15 pm 
Elliotte Rusty HaroldFeb 11, 2004 3:18 pm 
jco...@reutershealth.comFeb 11, 2004 4:20 pm 
Francois BeausoleilFeb 11, 2004 8:08 pm 
Trimmer, ToddFeb 12, 2004 11:57 am 
Elliotte Rusty HaroldFeb 12, 2004 2:53 pm 
Trimmer, ToddFeb 13, 2004 1:26 pm 
Elliotte Rusty HaroldMar 8, 2004 3:17 pm 
jco...@reutershealth.comMar 8, 2004 4:06 pm 
Elliotte Rusty HaroldMar 8, 2004 4:34 pm 
Elliotte Rusty HaroldMar 9, 2004 11:55 am 
Bradley S. HuffmanMar 9, 2004 12:09 pm 
Elliotte Rusty HaroldMar 9, 2004 1:05 pm 
jco...@reutershealth.comMar 9, 2004 2:04 pm 
jco...@reutershealth.comMar 9, 2004 4:32 pm 
Elliotte Rusty HaroldMar 9, 2004 10:43 pm 
John CowanMar 9, 2004 10:58 pm 
Elliotte Rusty HaroldMar 10, 2004 6:12 am 
Dirk BergstromMar 10, 2004 6:25 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[XOM-interest] Three cosmetic patchesActions...
From:Wolfgang Hoschek (whos@lbl.gov)
Date:Feb 10, 2004 3:23:48 pm
List:org.ibiblio.lists.xom-interest

Elliotte Rusty Harold wrote:

Here are some cosmetic patches against d24. The first two avoid some code duplication, and the third makes it a bit more efficient.

Have you measured this to prove it makes the code more efficient?

The first two patches make the code more readable and better structured, and performance difference should be negligible.

I presume you mean the third patch about iteration vs. recursion. Nope, i haven't measured it. But what i gathered from CS studies and benchmarks years ago is that iteration is always faster than recursion because it avoids function calls, stack allocations and deallocations, processor register state switching, allows better compiler optimizations because it increases optimization scope, better register allocation, etc. So the bottom line is it is faster (but i don't know how much) and it certainly isn't slower. I've heard mails a while ago on the list that sounded a bit uneasy about the potential performance hit of extensive tree walking for correctness checking, so I thought that patch would help and certainly can't hurt, given that the proposed code is just as clean, concise and understandable as the old one.

If you believe isAncestor() is unlikely to ever be a hotspot, the discussion is moot of course.

Wolfgang.