[PATCH] ipsum_calc_block: Optimize size and speed

[Joakim Tjernlund]

>
> On Fri, Apr 23, 2010 at 03:20:55PM +0200, Martin Mares wrote:
> > Hello!
> >
> > > 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.

But you can't get rid of:
 z + (z < sum)
which is the real bottleneck. Perhaps this doesn't cost much
on high end CPUs but it sure does on embedded CPUs

>
> > (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.