Eric Bezault:
> > What is too be done about it?
> > One possibility is to pull all that code out. That will mean gexslt
> > cannot conform to the standard.
>
> One temporary solution in order to keep gexslt compliant
> would be to have all the information kept in a binary
I think there are a few simple optimisations which should
be very easy to do and might help. I've only looked at
CTYPE classes, I presume the problems there are similar
elsewhere:
- Encode holes more efficiently, e.g. instead of:
<< -1, -1, -1, 100, 200, -1, -1, -1, -1, -1, 300 >>
assuming negative numbers are not otherwise used, use
them to encode the length of the holes:
uncompact_array (<< -3, 100, 200, -5, 300 >>)
uncompact_array fills the relevant number of -1 slots.
- Rewriting GEUC.write_integer_segment and friends to
work like GEUC.write_integer8_segment (using UTF8 for
arrays with > 256 items). Can be combined with
optimal holes above.
- Use routines for sparse planes:
eg.
UC_CTYPE_LOWERCASE.lower_code_plane_1
replaced with:
lower_code_plane_1_item (a_index: INTEGER): ARRAY [INTEGER]] is
-- Generated array plane
do
if a_index = 4 then
Result := lower_code_plane_1_segment_4
else
Result := empty_lower_code_segment
end
end
Instead of a size 256 array with 1 item! This is a particularly
extreme example, but aren't most of these plane arrays sparse?
I don't know where the cutting point is, but I'd be surprised
if an array makes sense below a few dozen items.
- If using arrays for planes, at least use Void to encode
the default case, if changing nothing else, replace all
the:
Result.put (default_case, ... many indices ...)
with one:
replace_void_with (Result, default_case)
at the end of the initialisation routine, when all the
non-default cases are not void.
|