[performance] AST walking twice

gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source

https://gno.land/

Other

842 stars 343 forks source link

[performance] AST walking twice #671

Open peter7891 opened 1 year ago

peter7891 commented 1 year ago

Currently, we parse the source code using a parser library and then we walk the AST and produce gno nodes. We should investigate if it is possible to avoid this. Ideally, we should create gno nodes during the parsing process. To do this, we probably need to fork the parser.

moul commented 1 year ago

I'm intrigued by this idea, but I'd like to explore other options before we commit to it.

We could try to identify the most recent point in the flow that only relies on source code and cache it. This way, we can perform a single parsing process and cache it during the AddPkg process, and store it in the GnoVM datastore alongside the source code.

We can further improve our system by exploring various optimizations, such as:

using LFU or Glicko algorithms to keep the most frequently used contracts in memory, and
using an LRU GC to remove inactive contracts from the disk store.

thehowl commented 1 year ago

As quick note; I agree with Manfred, but seeing as you were asking me for the chess algo, I don't think this is a good application for Glicko 2 :) (Glicko could be applied if you have direct comparison of one contract against a (single) other, which is not the case here).

Some alternative, "smarter" cache systems that could be used:

golang-lru, aside from good ol' LRU, implements TwoQueueCache and ARCCache.
groupcache is a library from the go team to serve as a library for replacing memcached nodes and is used in many google systems