[PATCH] ipsum_calc_block: Optimize size and speed
santiago at crfreenet.org
Fri Apr 23 15:48:51 CEST 2010
On Fri, Apr 23, 2010 at 03:20:55PM +0200, Martin Mares wrote:
> > Fairly, I once had the same idea for Quagga but found all those extra tests and
> > additions were much slower(I benched it). Just look at the number of extra ops one
> > has to do in the current code.
> > If you want to do it faster you have to go ASM. It would be easy to
> > add support for that too but it can wait.
> My primary reaction was "If something isn't broken, don't fix it." I.e.,
> unless you have good reasons for rewriting a piece of code, don't do that.
I agree. I would probably look at the Fletcher checksum, as the endianity
swapping before and after that is crazy, but would do benchmarking before
merging such change. But there are still several problems in OSPF that
should be fixed before doing some performance tuning.
> Your version is more readable and I would be in favour of accepting it,
> but I would still like to see at least a very simple benchmark which shows
> that it is not significantly slower.
OTOH, i think that most cases in the original code can be eliminated anyway,
because the buffer is always aligned.
> (Anyway, it might be interesting to run OProfile on Bird to see which parts
> of the code are real hot spots and where we should focus more on maintainibility
> than on speed.)
One thing which would probably be the most important on really big OSPF areas
is the priority queue in SPF (Dijkstra) calculation.
Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the Bird-users