Bug with the "builtin" vtable?

(1) By Florian Balmer (florian.balmer) on 2022-04-01 11:00:09 [link] [source]

While experimenting with the built-in files(*), I think I've found a bug with the (unused?) "builtin" virtual table. It looks like the first entry is omitted:

> fossil version

This is fossil version 2.19 [3500dbfd84] 2022-03-31 12:10:13 UTC

> fossil test-builtin-list -v | findstr /c:"entries"

107 entries totaling 697259 bytes

> fossil test-builtin-list | findstr /c:"accordion.js" /c:"fossil.diff.js"

  1. accordion.js                                    1284
 15. fossil.diff.js                                 13821

> fossil sql "SELECT count(*) FROM builtin;"

106

> fossil sql "SELECT name, size FROM builtin WHERE name IN ('accordion.js', 'fossil.diff.js');"

'fossil.diff.js',13821

(*) I was curious of the effects of compressing the built-in files regarding executable file size, image load time, and runtime speed. With file-by-file compression using zlib, the executable file size is reduced by more than 600 KB, but the duration to dump all built-in files is increased in the order of a few milliseconds. Not sure if this will be useful -- probably only for my Windows build, where I'm mostly using the CLI, and built-in files are less important. Also, for Windows I have implemented a library to compress and extract files to and from CAB resources using memory buffers instead of files, but no test results are ready, so far.

(2) By Florian Balmer (florian.balmer) on 2022-04-12 05:02:51 in reply to 1 [source]

... executable file size is reduced by more than 600 KB ...

I was picking the wrong number, it's slightly more than 450 KB, of course.

The solution to pack the built-in files into a CAB archive linked into the resources section is either larger or slower -- depending on the CAB folder size (i.e. size of compression units).

I was just using the "builtin" vtable for benchmarks.