InteractiveAdvertisingBureau
perf(decoder): avoid lots of calls to ensure data and field length/offset lookups
I've made three changes (three commits) to reduce the number of calls to ensureReadable() and to the LengthOffsetCache internal maps. We've seen 2x speed improvement in TCString.decode() and 2% overall CPU usage improvement in our production workload, which at high scale results in tangible cost savings.
Just to note, our use case doesn't benefit much from lazy decoding, since we need to decode the vendor consent, vendor legitimate interest, and publisher restrictions for almost all requests, and those three seem to dominate the decoding time in our profiling measurements when TCStringV2.hashCode() is invoked upon eager decoding.
Tagging some common contributors to help review: @laktech @imayankmishra @iabmayank @srinivas81
I also have another change on top of this where we make sure to use primitive int in decoding everywhere instead of Integer. Looks like that can squeeze out another 0.5% overall on our production workload. I'll submit that as another PR.
@laktech As promised, I've made a couple more PRs on top of this to test even further optimizations:
- (https://github.com/mkjois/iabtcf-java/pull/1) Avoids any boxed integers for a ~25% speedup.
- (https://github.com/mkjois/iabtcf-java/pull/2) A more speculative change to avoid lots of invariant checking in
BitSetfor a ~15% speedup.
Let me know what you think, when you're ready.
@laktech It wasn't a proper offline benchmark like with JMH or anything. I basically just tried it with a production-like workload as part of a much larger code path, and viewed some flame graph profiles. If you have any better JMH or other benchmarks set up, please feel free to test this out.
sorry i stepped away from this for a few months. i'll be reviewing this once again.
Overall, this looks great. I just have some concerns around the two areas I commented above.