Hi everyone,

How is everyone doing? Noticed it's a bit quiet on this mailing list, so I hope everyone is still alive!

This one has some slightly selfish connotations, because I'm having a lot of problems with disk full errors on my development platform when working with FPC (and running "make distclean" on my FPC source directory freed up nearly 700 MB of storage).  With these considerations, I would like to ask if it's possible to consider encoding some fields as LEB128 again -
https://bugs.freepascal.org/view.php?id=35299 (the first bit of the issue discusses an alternative encoding system) - this provides a significant saving on some fields without too much of a speed loss.  It was suspended because of concern with performance loss during quick recompilation, but considering the time increase was from 3 to 4 seconds or so, I don't think his issue is significant to be a concern because the total times are mere seconds.

I know in the modern age that hard storage isn't a concern for most, but it seems that in some situations, it can be, and LEB128 is otherwise a nice simple compression system for integers that are often very small but nonetheless need to support the full range.

Gareth aka. Kit

Op 2020-03-19 om 17:00 schreef J. Gareth Moreton:

(don't forget to once a year or so to svn cleanup the repos, this vacuums pristines)

True, every little helps.  It's just surprisingly difficult to test the compiler sometimes because of the amount of intermediate files that are generated.  Admittedly it's mostly my fault because I also generate assembler dumps when playing with the peephole optimizer!  I just figure a 10% to 15% saving on PPU files without any real penalty to full compilation and only a marginal performance loss to quick compilation is something worth considering again.

Still, I'll do svn cleanup first!

Gareth aka. Kit

Okay, that did something - that freed up 850 MB!

Gareth aka. Kit