Feature #6895
improve performance of BufferReference methods buffer() and definition()
0%
Related issues
History
#1 Updated by Eric Faulhaber over 1 year ago
RecordBuffer.buffer()
and RecordBuffer.define()
(declared by the BufferReference
interface, and implemented by every DMO proxy) stand out in the AspectJ method tracing as hot spots, just because they are called so often. They are invoked at the top of RecordBuffer$Handler.invoke
, if the declaring class of the method being invoked is BufferReference
.
These are invoked using Utils.invoke
, but considering they are used so frequently, perhaps an even more efficient, custom approach to invoking these, which bypasses the invocation handler entirely, would make sense. The ProxyAssemblerPlugin
interface exists for this purpose.
If fixing the Map.get
calls in Utils.invoke
(see #6819) does not resolve these hot spots, we will consider this as a further action. It should be noted that doing this may be complicated, because of the "double-proxy" approach currently used to manage buffer arguments and bind special cases.
#2 Updated by Eric Faulhaber over 1 year ago
- Related to Feature #6819: refactor FWD proxy implementation to use ReflectASM instead of Java Method reflection added
#3 Updated by Eric Faulhaber over 1 year ago
- Project changed from Base Language to Database
#4 Updated by Alexandru Lungu 6 months ago
Eric / Constantin: this task is related to #6819, but it seems that it addresses a more particular scenario (.buffer()
, .define()
). Do you still think this task is manageable in this (November) Sprint alone (i.e. separately from #6819)? We can start working on it if it still pops out in the performance tests.