D
dbeavon
Guest
Does anyone have any experience reporting performance bugs to Progress technical support? Has anyone successfully received a fix for a performance bug? We now run PASOE from a remote host (via client/server connections). When working with large datasets, I try to structure my programs in a way that retrieves all the prerequisite data in large batches (eg. starting with some initial queries that fill ABL temp tables via "FOR-EACH-NO-LOCK" or via ODBC queries). I had always imagined that where client/server performance is concerned, the "hard part" is simply to get the data out of the database and into the PASOE session (into local temp tables). I had hoped that we would be home free after that "hard part" was finished. However I'm now finding that even after the data has been placed in the PASOE session, we aren't yet out of the woods. The ABL runtime can still spend another 50% of the time doing CPU-bound work. If I look in the profiler, it seems that CPU bottlenecks can be located in the last place you would expect (running constructors, BIND'ing datasets, invoking methods, etc). I recently asked about performance problems with method invocations here: ABL Overhead Which is Due to R-Code Interpretation - Forum - OpenEdge Development - Progress Community Some people compare performance issues to the layers of an onion. You can peel back one performance bottleneck to reveal another and another. I understand that it is a never-ending effort. And I suspect that it is extremely hard to get a performance issue prioritized by technical support, considering that it doesn't cause a production outage and there is always a workaround (ie. wait longer). But I'm wondering if anyone has ever tried to report an ABL performance "bug" and successfully convinced Progress to fix it. I'd love to hear about it, and it may help me get brave enough to start opening tickets for some of the things that seem excessively slow in ABL. Please let me know.
Continue reading...
Continue reading...