[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: ABL performance bugs and technical support

  • Thread starter Thread starter Thomas Mercer-Hursh
  • Start date Start date
Status
Not open for further replies.
T

Thomas Mercer-Hursh

Guest
One has to be careful about what one calls a bug. We have certainly seen bugs over the years where a particular release had a sudden, dramatic decrease for an operation which previously had performed adequately and mostly I think these get fixed with reasonable promptness. But, it seems to me that the kind of thing you are having an issue with are more inherent to the nature of ABL ... not that one can't imagine some ABL like language performing better on that feature ... and, indeed, some pretty dramatic performance improvements have been introduced over time ... but that the performance you see today is similar to the performance you have seen since the feature was first introduced in the language. Some of these are things that only show up in tight loops with limited internal processing, i.e., operations which are not actually very characteristic of real world processing. If takes, for example, the time between the operator signals completion of the current screen until the time that a fresh piece of work is offered to the operator, a time when the operator is generally more tolerant of small delays,then is only certain specialized applications where the processing needed at that point is large enough to cause a meaningful delay end to end, so one has no concern that some particular piece of it is 100X slower than C or whatever. There are, of course, cases where that is not true like packing or routing problems which are a challenge in any language and are good use cases for the use of an external language. So, relative to your issue, I would say it depends. If there is something you find that used to perform meaningfully better than it does now, then certainly report it and I would expect it to receive meaningful priority. If it is something where you construct a test of a loop larger than one would ever likely use in a real world application and the test of slowness is a comparison to what you can do in C, then you might bring it to someone's attention but I would be surprised to see it get a lot of attention. I would also ask around and do some thinking about whether there may be a different way to approach the problem that is likely to be more performant in a language like ABL. E.g., running a method or internal procedure of an already instantiated class or procedure avoids the significant cost of instantiating a new class or procedure.

Continue reading...
 
Status
Not open for further replies.
Back
Top