I've just been through the whole engine, all the code, and learned a lot about how this stuff works! I'm planning on writing my own engine that works the same way but hopefully with a number of efficiencies. Just for fun, mind you. I enjoy a challenge...

I took a load of notes along the way for my own learning, but also have many suggestions and ideas for how things can be optimised, improved, potential bugs quashed, etc. Partly for when I come to code my version and explore that side of things. But I thought @perchance may find it useful.

This is just part 1 of what I learned and my "feedback" about various aspects of the engine code.

Easy Wins

Prototypes

Currently it seems all nodes have all those special properties added to them. Instead, (at least most of) those special properties could be part of some perchance_prototype somewhere. And then use Object.setPrototypeOf() to set the node's prototype to it, or make it in the first place with Object.create() to use the prototype.

That way you don't have definitions and functions on all those objects, just once on the prototype. But they'll all work the same. For a lot less memory, and processing time setting it all up.

String-to-number conversion

+string will convert it to a number, just like that.

Currently try-catch blocks and eval are used, but this doesn't seem necessary in particular. And, at least in theory, is less safe than simply telling JS you want it to be a number primitive.

Also means you don't need to do Number(string), which creates a new full Number object. (Different to a number primitive.) And so uses more memory, which will have to be garbage-collected as a lot of these are only temporary values anyway.

Checking if a string can convert to a number

Speaking of which, you can use isNaN(string) will be true if it is a string of a number, and false if it is not.

The code String(Number(string)) === string creates 2 new temporary objects in memory to be collected, and goes through a lot more processing than using the built-in function for this.

Converting to string

And on the other side, ""+val or val+"" will convert anything to a string, and automatically call its .toString() when available. (I think I saw this used a couple of times in the engine.)

Commonly String(string) is used, which again uses more memory than a simple string primitive.

Function nodes getter

(I'm talking about a fn_name() => for an inline or multiline function.)

Seems that a getter is used to build a new function every time it is accessed. Could be that I misunderstood the code, but it's how it appeared to me. If that's how it's working, it uses more memory for each call and wastes processing time making the function again.

Caching it somehow, even just making the function at load-time would save on all of that.

.replaceText()

Currently it splits and joins, creating a new array each time, so that it replaces all instances found instead of just the first one.

There is a built-in method on strings that does this already: string.replaceAll(find, replace), which doesn't create an array, so should be cheaper on memory. And (likely) quicker on processing too. And accepts a regex as well.

//- keep regexes/simple functions out of functions where they are called, // otherwise it creates a new one every time the function is called, // using more memory every time

Storing reusable objects out of functions

The kind of thing I'm talking about are regexes, for example /^\/\/.*$/.test(line).

And functions, for example array.map((value) => value.toLowerCase()).

In both those cases, the regex or function is recreated every time their parent function is called, using more memory. And when we're talking about some of the complex functions that are used everywhere this can really mount up.

Simply keeping them outside the function they are used in means that object (regex/function) is reused every time instead. And may potentially be reused by multiple different functions too.

//- reuse overriden selectMany (etc.) array.join function override, // to not create a new function every time it is processed.

Reusing overriding methods

A good example of the previous heading is, when an array is created and then has its own .join() or .toString() method added as a simple property. Currently that method is created each time such an array is made--using memory.

When these could all use the same exact function as their methods instead.

...

These are all just thoughts on easy low-hanging fruit that could be plucked for the benefit of how the engine runs. I'm not saying "do as I say" or anything like that, just putting these ideas out there.

Thanks for creating the platform in the first place, it's really fun 👍