Hello,
I've been investigating some performance issues with our application. When a user is doing repetitive data entry, their performance is gradually degrading after 20-30 consecutive edits. Initially, performance is very adequate with each operation taking less than 1 second despite interaction with the server and multiple calculations occurring in the callback from the server. However, as the edits progress, we are noting performance degrading very gradually but significantly so that it takes nearly 10 seconds to do the same operation that initially took 1 second.
We've inserted extensive debug logic to determine this is in fact a client-side issue and not related to server interactions. The slowdown is in the client-side callback. So, I've been using Firebug's profiler to try to better pinpoint the slowdown.
We are still sifting through our logic and trying to refine our investigation. But, one thing pops out as a significant difference between one of the early fast callbacks and the later slow callbacks. That is calls to logDebug() being reported by firebug profiler. They are taking an order of magnitude more processing time in the slow callbacks.
I am a bit confused by this because we are in fact using logInfo() for all of our logging to the dev console. We are not using logDebug() anywhere. And, these calls to logDebug are being reported by firebug profiler even when the dev console is closed.
So, are you able to help me understand why logDebug is getting called when we are not explicity calling logDebug() and the dev console is not even open? Is it possible there are some calls to logDebug() in your codebase that are not wrapped in recommended logic to check to logIsDebugEnabled() that could be impacting our performance as the user's session progresses? We are using 6.5.1.
Thanks for the help.
I've been investigating some performance issues with our application. When a user is doing repetitive data entry, their performance is gradually degrading after 20-30 consecutive edits. Initially, performance is very adequate with each operation taking less than 1 second despite interaction with the server and multiple calculations occurring in the callback from the server. However, as the edits progress, we are noting performance degrading very gradually but significantly so that it takes nearly 10 seconds to do the same operation that initially took 1 second.
We've inserted extensive debug logic to determine this is in fact a client-side issue and not related to server interactions. The slowdown is in the client-side callback. So, I've been using Firebug's profiler to try to better pinpoint the slowdown.
We are still sifting through our logic and trying to refine our investigation. But, one thing pops out as a significant difference between one of the early fast callbacks and the later slow callbacks. That is calls to logDebug() being reported by firebug profiler. They are taking an order of magnitude more processing time in the slow callbacks.
I am a bit confused by this because we are in fact using logInfo() for all of our logging to the dev console. We are not using logDebug() anywhere. And, these calls to logDebug are being reported by firebug profiler even when the dev console is closed.
So, are you able to help me understand why logDebug is getting called when we are not explicity calling logDebug() and the dev console is not even open? Is it possible there are some calls to logDebug() in your codebase that are not wrapped in recommended logic to check to logIsDebugEnabled() that could be impacting our performance as the user's session progresses? We are using 6.5.1.
Thanks for the help.
Comment