Similarly, I've been working on a faster interpreter for Python, making more tradeoffs than the existing alternatives do (e.g. no C ABI compatibility, no eval/exec, etc; but usable auto-migration for real-world projects) and achieving more performance. By now I've learned to ditch parser generators and I usually copy-paste-alter my own derivative-assisted (https://matt.might.net/papers/might2011derivatives.pdf) bottom-up chart parser.
It also makes a hell of a lot of use of 'continuous program optimisation' for performance, which I think should be in wider use. In general, the principle of adapting optimisations for the specific program seems to get neglected in favour of treating every program as though it were the lowest common denominator. (Say, maybe you need a top-down parser for your LSP server, but you can use a bottom-up parser for your compiler.)
I have a deep philosophical belief in eliminating wasteful computation – I think we as software engineers have a responsibility not to waste energy, in excess of the logical minimum required by the job at hand – so I have more of an interest in this than the bulk of programmers, who seem to regard performance engineering as some sort of nerd game that's rarely advisable.
It also makes a hell of a lot of use of 'continuous program optimisation' for performance, which I think should be in wider use. In general, the principle of adapting optimisations for the specific program seems to get neglected in favour of treating every program as though it were the lowest common denominator. (Say, maybe you need a top-down parser for your LSP server, but you can use a bottom-up parser for your compiler.)
I have a deep philosophical belief in eliminating wasteful computation – I think we as software engineers have a responsibility not to waste energy, in excess of the logical minimum required by the job at hand – so I have more of an interest in this than the bulk of programmers, who seem to regard performance engineering as some sort of nerd game that's rarely advisable.