D
dbeavon
Guest
At a very high level I'm interested in knowing what percentage of time is spent interpreting r-code vs actually doing the intended work. IE. assuming that it was possible for the ABL code to be jitted into native instructions, I'd like to know how much faster would that run than the interpreted R-code. It might help to have a concrete example. Below is a method FillInventoryLocationForProductType . It calls an interface method : IF NOT p_RelevantInventory: CheckPredicate (...). It calls the method 24000 times. ... The total elapsed time of invoking CheckPredicate appears to be ~600 ms. This is an interface method. Below is the actual implementation of that CheckPredicate (implemented by "mod2973_inputs"). The total elapsed time of the body of the implementation is ~300 ms. (that is the total for *all* of the 24000 iterations). The combination of both parts above takes about one second. The invocation of the interface method and the implementation of that method are entirely CPU-bound. The only work we are actually doing is to access temp tables with FIND statements. But in the process, we consume a total of about one second for all the 24000 iterations of the loop. Given that we are CPU-bound, I'm trying to understand if there is a way to refactor the code to make an improvement. But before I can start refactoring I need to understand how the CPU time was actually spent (~4 billion clock cycles of time). I would imagine that there is a significant portion which involves interpreting r-code. Perhaps if we could drill down to the r-code instructions or even get a measurement of the number of underlying instructions, then that might be used as a baseline for comparisons. Then I would simply refactor my ABL in a way that decreases the number of overall instructions which need to be interpreted. I might be going down an unnecessary rabbit hole here by asking for interpreter metrics.... The most glaring problem is simply that 24000 iterations of an interface invocation take ~582 ms. It seems clear that there is a performance problem with interface invocations in OOABL. At the same time, it would be helpful to have the low-level metrics that could be used to prove the point. It seems like the AVM interpreter itself should have some metrics which could be made available to us for profiling purposes.
Continue reading...
Continue reading...