support for caching

[notslang]

Some compilers (like HAML) already do this, but it would be nice to have a universal caching mechanism. Thoughts?

[jescalan]

Hmm, I don't know a ton about it, but I would be interested. Any ideas on potential implementation?

[notslang]

It's pretty simple, you hash the options & input string, that becomes the key in an object, and then the value for that key is the result of compiling the input string with those options.

So the cache object could look something like this:

{
    "vTFzjmJEH3MBFEspWxmmHhsQPpuir3": "<h1>Hello World!</h1>"
}

*that's not a real hash btw, I just smashed my keyboard a bit till it looked kinda like one

[jescalan]

Gotchya, makes sense. Interested in taking a stab at the initial PR for this?

[notslang]

Actually, I was totally wrong about needing a hash - JS has no limit for keysize so long as it fits in memory, because the key is just a pointer to a regular string in memory... nothing special.

But anyway, I'm thinking of using LevelUP for a persistent cache, shared between processes. Thoughts?

[jescalan]

This would have to be in a separate library I assume, and would require the user to also install leveldb?

[notslang]

I don't think so - it could be in a separate lib if you want, but caching is a pretty basic feature that should be beneficial like 99% of the time. As for installing leveldb: that can be done automatically via npm, if I'm not mistaken.

[jescalan]

Ok, I'm fine with this as long as it doesn't add any external dependencies and as long as leveldb brings any sort of speed or interface advantage to the cacheing over just using an object.

[notslang]

yep - the interface advantage is that an object can only be used in a single process, during the lifetime of that process. leveldb could be caching compiled files for days, with the cache still being accessible when you restart the process