Answered MODx Module is slow when printing large amount of text

I wrote a module for MODx using Ajax, it worked on dev server quite well but when I moved it online, one particular request got quite slow. This request generates around 120kB text but the weird thing is that what makes the request slow is printing, not generating. I used Firebug to measure the times. The request took ~100ms without printing the results, but ~400ms with printing... so the simple last echo command took itself 300ms! To find out more about this behaviour I just let the module print some pregenerated text of the same size without generating. Really just echo "120kB text". The request still took around 400ms. But then I run the script outside the MODx and suddenly it got really fast - just ~20ms!

So I suppose that MODx "does" some stuff around with the module output and makes it so slow. I tried to call exit right after the echo to stop the script but it didn't help.

I'm using MODx Evolution.

I'm not familiar with how Evo modules are set up, but I do know that in Revo you should use return and not echo. Not sure if that could even have a performance impact but thats the only thing coming to mind.. lol.

I wrapped the whole module with ob_start() and ob_get_contents() and returned the content but it didn't make any difference. I also repeated the test mentioned in my first post with simple 120kB text, I just used return instead of echo but again, result was the same.

BUT I tried something else and got even weirder results. Inside the module, I loaded using Ajax the big page, but completely from the outside of modx - no modx code involved - and it was slow. But then I called the same page but from the outside of the module and it was fast. Now it looks like JavaScript related... but how can JavaScript affect the speed of request?

Ok so after all, it really was JavaScript. I was using the old version of jQuery. I tried the newest and suddenly Firebug showed ~60ms instead of ~400ms. Funny thing is that although the numbers are much better now, the app still feels rather slow - I guess this was just some kind of jQuery/Firebug related bug and the actual reason why the app is slow is that 120kB of HTML code is just too much to be loaded into DOM So I won't avoid some heavy optimizations.

It's always what you least expect.. good that you figured out what's going on though.