Improving zcompdump (Re: A patch with hashtable optimization, which doesn't work)

[Bart Schaefer <schaefer@brasslantern.com>]

On May 20,  7:06am, Sebastian Gniazdowski wrote:
}
} There are no performance gains from keeping the collision list sorted.

Yes, I was going to reply to your earlier message to remark that I would
only expect sorting the collision list to *slow down* insertion ops, not
speed up lookups.

} Tried to optimize mkautofn, to speed up sourcing zcompdump.

How much does zcompdump actually help?  Have you compared startup with
and without it?

There's a bunch of stuff in .zcompdump.  Have you investigated whether
certain parts of it are slower than others?

One lesson learned with Completion/Base/Utility/_store_cache is that
parsing array assignments is expensive.  _store_cache now writes out
the array contents as a here-document and splits with ${(Q)${(z)...}}
to avoid parser overhead.  The _comps array is large; maybe there is
a big win to be had by changing the format of the file.