D
dbeavon
Guest
That is helpful. I did find the profiler in PDSOE, and used it for the first time a couple months ago. This is definitely the most thorough way to find performance issues, and it easily isolates the slowest parts of the code. I was pretty happy with the profiler; it was easy to use and it worked on the first attempt. >>You should profile compiled application... My question was related to my development environment. IE. when I'm doing development work on my local machine and I leave certain programs uncompiled, and something in the code is unexpectedly slower than it should be, then how can I quickly determine whether I'm being impacted by a compiler issue or by the logic of the code itself. One way is what you mentioned - to recompile the entire project and test again. But PDSOE compile operations on a large project are slow and hardly practical. Besides, much of the r-code should continue to remain uncompiled, if I'm actively making changes. As I point out above, the problem of performance (in the context of uncompiled code) is primarily only an issue in development. By the time code is promoted to production, the majority of it is already precompiled ahead of time, and there aren't many unexpected issues related to compiling ABL on the fly. (In production if there is still an impact related to dynamic compilation then it is usually enough to find it by monitoring for FileID in the client logs or use "-y" w/SHOW-STATS-CLEAR. These will tell us where the OE runtime is doing compilation operations that we might not expect).
Continue reading...
Continue reading...