Re: Precompiled wordcode zsh functions

[Zefram <zefram@xxxxxxxx>]

Sven Wischnowsky wrote:
>I forgot: there is a problem with this which I remembered at the
>weekend. The word-code isn't really machine-independent, it depends on 
>the endian-ness.

Does it depend on the length of int too?

>With that a standard installation could:

The obvious clean solution is to define an architecture-independent
wordcode format so that the saved wordcode is shareable.  However,
I expect that would have an undesirable amount of overhead.

Next possibility is to have saved wordcode files contain wordcode for
both endiannesses.  Wordcode files get twice as big, but the unneeded half
can be so completely ignored that it never gets paged in at all.  I don't
think that address space usage is a significant concern at this level.

Next possibility: separate wordcode files for different endiannesses
(and possibly different int sizes).  Have .zwcb and .zwcl suffixes.
When looking for the file for an individual function, only look for the
appropriate suffix; digest files are ignored if they are of the wrong
endianness (determined internally).

On the issue of digest files versus individual function files, I think we
should have both.  A .zwc file in a directory in $fpath acts exactly like
a normal textual function definition file, except that it is in wordcode
instead of text; it should take precedence over any file (of either type)
further down $fpath, but we may want to do a date comparison if both
textual and wordcode files exist in the same directory.  A digest file
should actually be listed in $fpath; its definitions take precedence
over directories (and digest files) further down $fpath.

We should probably have some size theshold to switch between reading and
mapping wordcode files; e.g., any file over two pages long gets mmapped.

-zefram