In most cases beforeRenderModule info is useless - it has a minimal time and negative memory usage:
Application 1.907 seconds (+0.001); 11.05 MB (-0.014) - beforeRenderModule mod_hellome (Hello Me)
The debug info actually becomes unreadable, afterRenderModule is more informative is really useful.
It certainly depends on what a Module does... let if fetch data from an external source or service and you might get very different results.
I'd rather see this turn into a proper Event, onBeforeRenderModule in JDocumentRendererModule:.render(), where Plugins can access the Module data, params, and attribs. It'd make Modules equally important and extendable by Plugins like components are today.
That would also make the recent addition of JHtml::_('content.prepare') kind of "obsolete", since the same content plugins can then also register for onBeforeRenderModule to perform the very same thing, i.e. simply "forward" the job to their existing onContentPrepare handler -- or decline to do so, since the $context would then be different of course.
That would make the debug information in afterRenderModule even more valuable :-)
Events onBeforeRenderModule can affect performance
yeah, funny, and thanks for the laugh :) You made my day!
Calling a method in already loaded php file on an already instatiated object is sooo much slower than doing DB requests elsewhere ;-) Crunching the wrong numbers ain't gonna cut it...
Nothing funny here if you trace triggering even 1 registered handler which will use preg_replace() for 25 modules on page. Sure it is funny if your site has 50 visitors a day.