Hi!
I have a proposition for optimizing big case statements with sparse case
labels. Have you already thought of using a hash function to drastically
reduce the size of the jump table?
I have made some tests. For example, assume a case statement with 80
values for case labels in the range
For that very reason, I put an upper limit of 2,048 on the jump table size
(which results in an 8 KiB table), although it was modified later so this
bound doesn't apply if every single label points to a single value and more
or less forms a continuum (e.g, you have 2,500 labels and none of them
Am 14.01.2019 um 15:01 schrieb J. Gareth Moreton:
> Martok mentioned doing some checks differently in the bug report in question,
> such as 6 comparisons being faster than a jump table. Are there any others
> worth mentioning?
Not neccessarily faster, but in that code definitely smaller. Is there
Aah cool. Thanks for that tip. Hmmm... I see "riot" in the flags... I
think it's going to be a riot with the errors found!
Gareth aka. Kit
On Mon 14/01/19 18:17 , Pierre Muller pie...@freepascal.org sent:
Hi all,
Le 14/01/2019 à 15:01, J. Gareth Moreton a écrit :
> Hi everyone,
>
Hi all,
Le 14/01/2019 à 15:01, J. Gareth Moreton a écrit :
> Hi everyone,
>
> I apologise I didn't properly test my case block improvements, especially
> where optimising for size is concerned. As someone who has worked in SQA, I
> should have known better.
>
> I've also spotted a potential
