Don't allocate if the caller to fast args does not obtain an object

[AnsisMalins]

Currently, when there are any objects in the argument list, V8FastArgs allocates managed heap memory even if they are never accessed. Also, any additional API to access V8 objects in a non-allocating way depends on this change.

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.

My goal is to have zero unsolicited allocations when responding to calls from JavaScript through V8FastArgs. If this pull request is not to your liking, tell me what you would accept, and I'll try to make that.

[ClearScriptLib]

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!

[AnsisMalins]

Would you accept a pull request where the objects array is pooled? Would you accept a pull request where accessing non-object arguments avoids calling GetObject and so avoids creating V8ObjectImpl instances?