Re: size of emacs executable after unicode merge

[Thomas Lord <lord@emf.net>]

Stephen J. Turnbull wrote:
>  > If it would be helpful,
>
> Did you do much better than 60% savings? 


As I recall, I did considerably better, though I'm not clear whether or not
we're talking about the same tables.   I could be mistaken, hence the 
passive
request for prompting to indicate whether or not it's worth really 
refreshing
my memory here.

You are on the right track to observe that the density of stuff that matters
is the key to optimization.

Trie-based sparse-away approaches seem to work very well.    The trick
is to do some off-line computation to work out a roughly optimal breadth
and depth.   I found it worked well to vary the breadth according to depth.
That's, in a nutshell, what I'm talking about.


You talk about range encoding.  Ick.  Too many tests and branches, in my 
experience.
A simple trie will do -- just take care to get its shape correct.

> In other words, even with a naive strategy, the Unicode BMP database
> should only add about 1.1MB to 1.4MB, ie, about 10% of the size
> increase seen here, if coded compactly but straightforwardly in C.
>
>   

I'm not talking about boatloads of code and, if done right, it has other 
applications
as well.

It's no big deal either way.  I don't mean to argue.  I just thought it 
might be helpful.
I'm just a patzer or kibbitzer here, take yr pick.

As an aside: virtual memory hardware sucks and is pointless.   
Segmentation rocks, on
the other hand.   But, that's a topic for a day a ways in the future, 
unfortunately.

-t