Hey, thanks for building vellum, it's awesome!
I have a service which uses vellum's FST for searching needles in a haystack, and while profiling it, I found significant overhead at the calls to IsMatchWithVal and AcceptWithVal, both of which are linked to decoderV1.stateAt -> runtime.newobject.
I took at look at the code and found it's due to stateAt heap allocating a fstStateV1 at every call to IsMatchWithVal and AcceptWithVal. In other words, heap allocation occurs for every character in the string being searched on.
I hacked a patch (see next comment) and found the service to reduce its response time by half. So I guess this is significant enough to discuss upstream.
Hey, thanks for building
vellum, it's awesome!I have a service which uses vellum's FST for searching needles in a haystack, and while profiling it, I found significant overhead at the calls to
IsMatchWithValandAcceptWithVal, both of which are linked todecoderV1.stateAt -> runtime.newobject.I took at look at the code and found it's due to
stateAtheap allocating afstStateV1at every call toIsMatchWithValandAcceptWithVal. In other words, heap allocation occurs for every character in the string being searched on.I hacked a patch (see next comment) and found the service to reduce its response time by half. So I guess this is significant enough to discuss upstream.