The current GBContext implementation is suboptimal for java backend integrations.
We have to create a new GBContext for each request, and because the CustomGbContextBuilder only supports StringType featureJson, we have to pass featureJson as string and it parses the JSON (converting from String to JSONType) for each and every request.
This can be avoided by letting the application maintain JSON and set JSON directly.
Flame graph with the current GBContext:
As we can see, around 42% of total CPU is spent inside parsing this JSON for each and every request, this overhead can be clearly avoided by letting the client set the JSON directly instead of string.
The current GBContext implementation is suboptimal for java backend integrations. We have to create a new GBContext for each request, and because the CustomGbContextBuilder only supports StringType featureJson, we have to pass featureJson as string and it parses the JSON (converting from String to JSONType) for each and every request. This can be avoided by letting the application maintain JSON and set JSON directly.
Flame graph with the current GBContext:
As we can see, around 42% of total CPU is spent inside parsing this JSON for each and every request, this overhead can be clearly avoided by letting the client set the JSON directly instead of string.
After the fix:
The stack frames for transformFeatures went away.