Speed of UPARSE

[bradrn]

@hostilefork

Rules of program optimization:

1. Don't do it.
2. (Experts Only) Don't do it... yet.

And that’s how you end up with slow software!

To make myself entirely clear, this is certainly a position I can sympathise with. My main language is Haskell, which is difficult to optimise, so often I don’t bother. But Haskell still makes it possible to write fast programs, and eventually there comes a time when I do need to dig into the internals and speed up my code. It’s hard, but certainly worth the effort.

@hostilefork

But to give you a sense of the tip of the iceberg: UPARSE uses raised ERROR! object antiforms on each unsuccessful match. This means that other values are "in-band" as potential synthesized combinator results (including packs). But it also means that for a combinator to fail, it has to make an object.

This is interesting… to me, this sounds more like an issue with the interpreter being too slow, rather than UPARSE itself. What makes objects so slow to construct?

@hostilefork

Perhaps it's time for you to get your hands dirty and read to understand what UPARSE is doing in terms of how it is implemented

I have been doing so, on and off, when I get the time. It’s difficult code to understand, and I can’t say I understand precisely how it works yet, but I do at least have some vague idea of what the major components are.