Re: [PATCH] Sort kallsyms in name order: kernel shrinks by 30k

[Rusty Russell]

On Tue, 2004-05-11 at 18:08, Andi Kleen wrote:
> On Tue, May 11, 2004 at 03:08:55PM +1000, Rusty Russell wrote:
> > Admittedly, anyone who sets CONFIG_KALLSYMS doesn't care about space,
> > it's a fairly trivial change.
> 
> As long as nobody does binary search it's good. Wonder why I did not
> have this idea already with the original stem compression change ;-)

ISTR that someone (I thought you) mentioned doing this before.

In general this code was considered non-speed-critical, but Keith points
out its use in wchan.  A simple cache might make more sense there,
however.

A binary search as stands doesn't help much because we still need to
iterate through the names.  We could do "address, nameindex" pairs, but
with stem compression we need to at least wade back some way to decode
the name.

I have a 30-line static huffman decoder (from the IDE mini-oopser) which
we could use instead of stem compression, which we could combine with
"address, bitoffset" pairs which would be about 20k smaller and faster
than the current approach, but is it worth the trouble?

Thoughts welcome,
Rusty.
-- 
Anyone who quotes me in their signature is an idiot -- Rusty Russell

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/