Hi @AnsisMalins,

Thanks for posting your PR!

I argue that preemptively allocating objects and caching them in an array only makes sense if you expect the caller to call V8FastArgs.Get on the same argument many times. But that case does not exist. A caller who uses FastProxy cares about performance and can be expected to call V8FastArgs.Get only once and store the result in a local variable for reuse.

It really isn't that simple. Performance means different things to different people. You could be after speed, efficiency, scalability, responsiveness, predictability, throughput, etc. – or some combination. One can’t optimize for everything, and FastProxy doesn’t try, but as a general-purpose API, it can't play favorites either.

Your proposal certainly improves the single-Get case, but it breaks the multiple-TryGet case, which we feel is important, as FastProxy doesn't support overloads. Your change also doesn't address the singular V8FastArg API and appears to be incomplete.

Having said that, we hear you. There should be a way to bypass or defer the allocation of the object cache. We like the zero-allocation goal, as it benefits pretty much all performance seekers. It's why FastProxy has its unorthodox API design. You're right; the current implementation falls short for your use case, but we believe it can be improved without changes that break or compromise other use cases.

Cheers!