Will there be a speed-up when using a Dlang switch-case and shorter pegged variable names?

[enjoysmath]

Will there be a speed-up when using a Dlang switch-case and shorter pegged variable names?

[veelo]

Not likely. This is an interesting general D question, and it could be worth asking on the learn forum.

In principle, string switches have the potential to be just as fast as enum switches, if the compiler is able to compare pointers to strings in static memory. That is not always the case, and I don't think Pegged grammars is one of them, sadly. (It would be nice to experiment with generating parsers that use an enum instead of strings.) So if a jump table is not possible, a large if () else if () else … is generated, in which strings are compared.

String comparison can fail early: as soon as two characters differ, the strings cannot be equal. So if you have 24 sentences that all start with a different letter of the alphabet, every one of them can be differentiated by comparing just the first letter.

In your short example this is already the case, so I would expect that you will see no change in speed whatsoever.

If you have a very large grammar and are looking for ways to speed things up, you should first see if there is any left recursion in it (as that cannot be fully memoized). If you have a lot of time on your hands you could try modifying Pegged to generate enum based grammars; I would do it if I had the time.

[enjoysmath]

So in essence, I should just use my long-name version for readability?

…

On Sun, Oct 30, 2022 at 3:01 PM Bastiaan Veelo ***@***.***> wrote: Not likely. This is an interesting general D question, and it could be worth asking on the learn forum. In principle, string switches have the potential to be just as fast as enum switches, if the compiler is able to compare pointers to strings in static memory. That is not always the case, and I don't think Pegged grammars is one of them, sadly. (It would be nice to experiment with generating parsers that use an enum instead of strings.) So if a jump table is not possible, a large if () else if () else … is generated, in which strings are compared. String comparison can fail early: as soon as two characters differ, the strings cannot be equal. So if you have 24 sentences that all start with a different letter of the alphabet, every one of them can be differentiated by comparing just the first letter. In your short example this is already the case, so I would expect that you will see no change in speed whatsoever. If you have a very large grammar and are looking for ways to speed things up, you should first see if there is any left recursion in it (as that cannot be fully memoized). If you have a lot of time on your hands you could try modifying Pegged to generate enum based grammars; I would do it if I had the time. — Reply to this email directly, view it on GitHub <#319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMIF56UU6SKEHQ5ZQBM3GLWF3O4BANCNFSM6AAAAAARSMRMMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>