Lightning wrote:
In Utf8Case.php we have this huge ~1450 item
associative array (
$wikiUpperChars ). Is this really necessary? Is there a way we could
avoid having to load such a huge array into memory for every pageview
by a user in a language that needs it? This seems like it could pose
to be a problem in the future.. maybe keeping it in shared memory so
we dont have to go regenerating it and having all these instances of
it for every page view? I guess at the time its OK but as UTF8 wiki's
gain more and more popularity this might become a problem. Or am i
completely wrong?
There are several things to note here:
* We're using PHP-Accelerator, which caches the parsed opcodes in shared
memory as long as the PHP files don't change. The source code isn't
parsed on every page view.
* The performance of the functions using the array may be more
significant than its inclusion.
Do feel free to do some benchmarking and suggest alternate methods.
I'm noticing in setup.php that we are include()ing
a whole lot of
stuff. Some of this stuff might never even be used, so why are we
include()ing it? We should probably include JUST what we need, this
would probably save a little tiny bit of memory and processor. I know
it's not much, but at the same time, why waste at all when we don't
need too? Same thing for Skins.php, it include()s all 3 skins. could
we just include() the one we need?
Probably could. Would it make a difference? Try it.
Is there a possibility of keeping the banlist in
shared memory? Since
every single hit requires a query to that table, it might help if we
keep it cached in memory so we can avoid unnecessary querys and load
on the db.
The banlist is checked only on login and article save, not on every hit.
On the other hand, user info is loaded for every hit by a logged-in user
and newtalk is checked for every single hit.
More use of session variables and the possibility of shared memory may
be worth looking into (please feel free to do so). Keep in mind though
that people may be using the same account in multiple browsers
simultaneously, and it would be good to make it easy and safe to use
multiple front-end web servers talking to the same database server
[cluster].
I think the banlist cache and the limiting include()s
are my most
reasonable proposals. I also think they would be the easist to
implement. thoughts? The ban list thing could be implemented fairly
quickly, and it might help with performance.
Please test and benchmark all suggested performance improvements.
-- brion vibber (brion @
pobox.com)