nomennescio

NOTE: this code has *no* impact on uncompressed images, i.e. no impact on startup timing. That is, it's fully transparent w.r.t. current uses of Factor.

> Is it really 50ms of overhead? > > That's a lot of overhead versus running no code: > > ``` > $ time ./factor -e="" > > real 0m0.098s...

> Should we link against a compression library instead of including it directly? I thought of that, but that is unsafe; so early in the vm life cycle phase, we...

> > Should we link against a compression library instead of including it directly? As a mitigation of the slight increase in executable size due to static linking, I was...

> Is it really 50ms of overhead? > > That's a lot of overhead versus running no code: > > ``` > $ time ./factor -e="" > > real 0m0.098s...

I'll also be doing a compression experiment with a `load-all` image; if we can practically start using that, then run-time loading of vocabs can be prevented at all.

> I'll also be doing a compression experiment with a `load-all` image; if we can practically start using that, then run-time loading of vocabs can be prevented at all. Got...

> What issues did you have with load-all? Just missing dlls, and one accidently bound (?) to Outlook which gave a funny warning: ``` (process:17792): GLib-GIO-WARNING **: 14:21:52.240: Unexpectedly, UWP...

> time ./factor -e="" Right, thanks for the feedback; I ran a single time on my Windows machine ``` $ time ./factor.com -i=factor.image.compressed -e="" real 0m0.982s user 0m0.000s sys 0m0.015s...

> Those times don’t look right. I think your Factor is loading stuff on startup maybe your -rc file. Run factor, then ‘save’ then try the compare again. Yes, it...