Profiling: constants and variables

2006-03-29 01:33:02

I've just installed xdebug and kcachegrind to play around abit, get to know it and try to improve the world's best blogsoftware.

So I installed a fresh copy of serendipity1.0-beta2 on my laptop and started.
Here's the file: cachegrind.out.680592437 and a screenshot

First thing that came to my attention that uses 20,3% of the time spent. This can't possibly be and so I first thought of the multibyte stuff - nope. Then I realized that we have a 800 line file with define()s in it for every language. So I moved some of them away and voil´┐Ż - no more language stuff near the top.

Then I made this script:

which produced following output: cachegrind.out.2897431826

Oh yes, variable assignment is 20x faster and so we could reduce 20% of time spent rendering a page to 1% by rewriting 90% of all files. Perhaps it would be better to store them in the database and just do a global search&replace with `LANG_CHARSET` becoming `$foo['LANG_CHARSET']`.

Stay tuned for more interesting profiling stuff, as I could scream for not having tried this before :P Linux on the desktop is at least good for anything but grief :)

graph with 7 entries on frontpage
screenshot with 7 entries

`serendipity_event_emoticate.php` sucks 1-2% performance, could be fixed by using strtr()
`serendipity_makeFilename()` uses 4% of total time, maybe there's room for improvement.
Other intensive stuff: serendipity_plugin_api::hook_event - 19,85% - 24 calls - 5,92% - 1 call
Smarty->plugin_calendar.tpl.php - 6,97% - 1 call
Smarty->index.tpl.php - 3,93% - 1 call
language stuff - still 4% - 1 call
Smarty->_fetch_resource_info - 3,49% - 5 calls
Smarty->entries.tpl.php - 3,16% - 1 call
serendipity_event_s9ymarkup - 2,47% - 14 calls
serendipity_printEntries - 2,20% - 1 call


Life's a bitch, life's a whore. Nothing less, nothing more.

Read More