D
dbeavon
Guest
What I was trying to point to in my original post was that I have a 300 ms overhead that is *not* database related. The 100ms variation of the ABL code and the 400ms variation of the ABL will *both* get the same data into memory buffers in the same FOR EACH loop. The ABL language/organizational choices that are made *within* that (3000-record) loop is what adds 300 ms to the entire duration of the round-trip. (ie. about 1 ms per ten records). I realize that this is a bit abstract without seeing the code itself. I was hoping someone would corroborate my theory that private method invocations may be largely responsible for the overhead. I am hearing, at the least, that private method invocations are not free in ABL. Coming from a .Net background, it is a shock to see this contribute a substantial part of the 300 ms overhead. Breaking business logic into private methods seems like a code maintainability topic more than anything else. It would be like telling me that I can only add three lines of comments to each iteration of my FOR EACH loop and not more. I understand that classic ABL procedure invocations are quite a bit more "dynamic" than they are in other languages. However, my hope was that OO methods were more strict and that the invocations of them, being better checked by the OO ABL compiler, would have reduced overhead at runtime. I think there is much to be gained if Progress would start addressing performance issues in the ABL language as well as in the database. 300 ms is a lot of overhead for fetching such a small number of records. Otherwise I may need to go back to using compile-time include files for my inlining in some cases (scary as the thought may be). If anyone can point me to guidelines ('dos' and 'don'ts') to help my organize ABL for better performance, I would appreciate it. Some of these rules are certainly *not* self-evident (eg. the ASSIGN rule, the need to use moderation with private methods.)
Continue reading...
Continue reading...