You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right, I keep uncompressed versions of the top 3 (or so) for each edition of js1k and use them as benchmarks, to illustrate progress among revisions of RegPack :
There are two independent reasons for this difference :
The fix for #57, present since v5.0.0, which prevents _ from being (incorrectly) renamed to A inside a string. Using _ as an extra token was worth 2 bytes, yet it was definitely a bug. The sample packed with v4 would decode incorrectly, yielding a glitch in the dragon sprite.
Those 2 bytes will not be regained => won't fix.
The fix for #65 introduces a bias in the crusher. The output is correct (meaning it unpacks to the initial code) but suboptimal as far as compression is concerned.
The sample code contains a string with several escaped \ (thus represented as z="\\").
As RegPack stores the code in a (compressed) string, it also escapes all \, turning the already escaped backslash into G='z="\\\\"'.
v4 performs the escaping before running the crusher. Initial sequences of \\ are escaped as \\\\, counted as 4 bytes and packed as such.
v5 performs the escaping after running the crusher, because of #65. However, \\ is counted as 2 bytes, and therefore not considered worth replacing with a token.
Proposed solution : when computing string length in the crusher, count 2 instead of 1 for each \.
Siorki
changed the title
Size regression on benchmark "Flappy Dragon" between v4 and v5
Regression in v5 - Suboptimal packing due to incorrect assumed length of escape sequence
Oct 13, 2018
Benchmark "2014 - Flappy Dragon" run with different revisions of RegPack :
Digging further, the crusher phase differs, v5 shaves a few bytes off the unpacking routine using ES6 (see PR #53)
_
The text was updated successfully, but these errors were encountered: