https://bugzilla.wikimedia.org/show_bug.cgi?id=22018
--- Comment #8 from Domas Mituzas <domas.mitu...@gmail.com> 2010-01-05 15:11:47 UTC --- I've read some books, but unfortunately they've all been about internals or performance :( Anyway, my point was that one has to understand where are the slow parts before making any claims. As for parsing issue, start with http://blog.libssh2.org/index.php?/archives/92-Understanding-Opcodes.html For installations without opcode cache I will suggest installing opcode cache. We do work a bit to make mediawiki better for them (look at whole autoloader effort :), but we won't spend unreasonable resources for something what can be fixed by installing a cache. "500 lines with paths" is not necessarily bad - it compiles into nice in-memory array in opcode caches, which is really cheap to query, and doesn't cause unnecessary calls to filesystem. Anyway, we welcome contributions, but if you want to be a drama queen, feel free to find another project to contribute. I'm not PHP pro, I don't know how to write brilliantly elegant code (we have Tim for that ;-), but I prefer profiler output to opinions of people who have never really written high performance software. Cheers! -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
