Re: Why sourcing a file is not faster than doing a loop with eval, zle -N

[Sebastian Gniazdowski <psprint@zdharma.org>]

On 17 Jun 2017 at 18:39:55, Bart Schaefer (schaefer@brasslantern.com) wrote:
> On Jun 17, 5:44pm, Sebastian Gniazdowski wrote:
> }
> } So the gain from zcompiled .fsh_cache seems to be maximal.
>  
> As long as you've got a good way to test these timings ... compile
> your .fsh_cache file with "zcompile -R" and see if you still get
> any speedup?
>  
> Some simple tests that I did seem to indicate that zcompile does
> not do much good if the default "zcompile -M" behavior is disabled.
>  

No problem. The results seem the same, best "zcompile" time (previously reported): 0.375 s, best "zcompile -R": 0.376 s. Did this twice after anxiety that I forgot "-R" (very unlikely): 0.374 s.

BTW, I have a whacky idea:

1. Invoke "source_prepare ~/.plugins/aplugin.plugin.zsh.zwc", etc. for all used plugins
2. Continue with normal zshrc
3. After it, invoke source_load with the same paths
4. source_prepare will use threads to load .zwc files
5. There will be internal hash table mapping paths to Eprogs, mutexes
6. If the Eprog is not yet ready, source_load will hang on mutex

This is to: perform normal zshrc execution while loading of bytecode in background. I checked that ~/.fsh_cache.zwc is 158 kB in size, quite much. But all this is probably a lost game, the mutex use, thread creation, will waste the gain. Although a cool thing to code, I think I will do it anyway.

--  
Sebastian Gniazdowski
psprint /at/ zdharma.org