D
dbeavon
Guest
I can understand how a large regression in performance would get some attention. That seems straightforward. What about if I can prove that, everything else being equal, something in particular like "BIND" parameters take substantially more time on one supported OS/platform than another? Or what if a method has an artificial concurrency issue that forces the ABL to wait on a resource which shouldn't be shared . Eg. community.progress.com/.../57795 Or what about local method invocations that take 1 ms each? or 100 ms? or 1000 ms? What is the upper limit before Progress would be convinced that it is a performance bug? It seems like there should be some guidance that could reference to help us determine what is worth submitting as a bug and what is not. I'm finding that the CPU bottlenecks in ABL becomes very significant when working with "larger" datasets (eg. data for 10,000 or 100,000 transactions). One technique to overcome these CPU bottlenecks is to initiate work on PASOE in *parallel* (eg. using TPL in .Net with Parallel.Foreach). This can allow us to send five or ten requests to PASOE to run in parallel on multiple ABL sessions at once. A core that is being used by a .Net process can keep up with quite a lot (5-10?) of cores running ABL. This discussion is, of course, related to some "real-world processing" that we are dealing with. The fact that I'm working with "larger" datasets (10,000 transactions of data rather than 10 transactions of data) doesn't make the problem any less "real". The question may ultimately depend on what Progress considers to be a "large" dataset. Are there any sample ABL applications that ship with OpenEdge or can be found on github? Maybe there are some OOABL programs to go along with the "sports2000" database? It would be nice to have some benchmark/reference for my comparisons. Maybe something like this would help whenever I'm opening a meaningful & convincing support case about ABL performance. Ideally Progress would be a partner in solving performance problems. There is a limit to the types of performance issues that customers can fix on our own (especially when the profiler identifies problems outside of our own custom code).
Continue reading...
Continue reading...