D
dbeavon
Guest
I was able to change the performance of this invocation by refactoring the code.... Instead of calling an interface method, I started calling an internal method on a persistent procedure handle. The performance difference in the invocation was only an improvement of about ~200 ms for 24000 iterations. Whatever performance I was gaining in one place was lost in another. I eventually abandoned the effort. My primary complaint is that the profiler in ABL only gets down to the *statement* level, and this may not be granular enough. Your program can still waste 100's of milliseconds on a moderate-sized dataset without any really good explanation. We don't seem to have the metrics that we would need in order to figure out why the method invocations are slow. The method invocations seem slow to me since they consume ~600 ms for 24000 iterations . A similar test in C# was about 100 times faster. The conclusion is that ABL programmers should avoid methods. IE. we can write faster code by avoiding the use of smaller methods (especially in a loop with lots of iterations). The cost of the method can exceed the "real" work done within it. Perhaps the avoidance of methods could be accomplished if we go back to all the include files that we used back in the good ol' days. I'm assuming that the overhead is interpreter-related but, as you say, there is no way to know for certain. It could be related to functionality differences since C# passes strings by reference and perhaps ABL copies data around in memory before calling the method. Or there could be some other mysterious performance cost that is hidden deep within that statement.
Continue reading...
Continue reading...