Hello,
Yesterday I have been made aware of a built-in profiling tool in
MediaWiki. I played a bit with it and wondered if I could implement such
a tool for another project.
This afternoon I finally found a good way of profiling mediawiki cpu
usage, a picture of the result is at:
http://www.twenkill.net/phpprofiler.png
(might be unavailable depending of my home connection status).
Using debian GNU/Linux, following is a little howto to get the same
window opening on your screen.
1/ PROFILER
Install the profiling tool: apt-get install php4-apd
To enable profiling in mediawiki edit your index.php file and insert at
top: apd_set_pprof_trace();
Now each time a web request is made on your website, a file
pprof.<apachepid> will be generated in /var/log/php4-apd/
This is a serious performance eater and should only be enable when you
need profiling outputs !
2/ GUI FRONTEND
The gui frontend I use is Kcachegrind: apt-get install kcachegrind .
As far as I understand, it uses Caltree profiling tool and Valgrind to
make a graphical representation of a C software.
KCacheGrind isn't able to read pprof file format so you will have to
convert it. A script is available at:
http://cvs.php.net/co.php/pecl/apd/pprof2calltree?r=1.3
Eventually edit it so it looks like /usr/bin/pprof.
Then convert the pprof file:
$ pprof2calltree -f pprof.29539
Writing kcachegrind compatible output to cachegrind.out.pprof.29539
$ ls
cachegrind.out.pprof.29539 pprof.29539
$
If pprof2calltree start outputing lot of lines, you need to raise the
memory usage limit in your cgi php.ini file ( /etc/php4/cgi/php.ini ).
Now launch kcachegrind:
$ kcachegrind cachegrind.out.pprof.29539
Note:
You will need the graphwiz library to generate the call maps: apt-get
install graphwiz.
Enjoy ! :o)
--
Ashar Voultoiz
[[fr:Utilisateur:Hashar]]
Otherwise when a user chooses "Leave it as TeX" he always gets "$ $"
which is not that useful :).
Laurent
--- Math.php~ 2004-06-06 21:14:58.655353058 +0200
+++ Math.php 2004-06-06 23:26:07.026770706 +0200
@@ -30,7 +30,7 @@
if( $this->mode == MW_MATH_SOURCE ) {
# No need to render or parse anything more!
- return ('$ '.htmlspecialchars( $tex ).' $');
+ return ('$ '.htmlspecialchars( $this->tex ).' $');
}
if( !$this->_recall() ) {
Hello,
I am willing to know which formatting method we should use in code for
function declarations. Actually I see two shemes:
1)
function foobarone() {
code here
}
2)
function foobartwo()
{
code here
}
The reason I am asking for this, is that my code editor (anjuta) add a
little + sign in front of functions and clicking it will remove all of
the code between {} and show an horizontal bar instead. That looks like:
function foobarone() {
-----------------------------------
function foobartwo ()
{
-----------------------------------
So sheme #1 save one line :o)
That's really minor, but before I start changing all functions
declaration to one sheme or the other I would like to get your feedback :)
--
Ashar Voultoiz
[[fr:Utilisateur:Hashar]]
It seems there is reasonably strong support for running Debian on the
new 1Us. Shaihulud, gwicke, jeronim would like Debian; I remember there
was also support for it from various people here on tech-l. Again, it
would make system administration and maintenance considerably easier and
more manageable.
The only objection that was raised to Debian on the list was that it
doesn't have a stable 64-bit release, which clearly isn't an issue for
the P4s. Also, since I'm told Jimbo is unfamiliar with Debian (which
might be a problem during the installation), I'd like to point out that
you can install Debian pretty easily from a Knoppix CD. Only a barebones
install is needed - the rest can be done over ssh.
Cheers,
Ivan.
Hi,
Why don't host IRC chanels on wikimedia servers ? (ie. irc.wikimedia.org)
Freenode may vanish day, we have better to get ready for that.
It may be also nice to offer people under firewall a Web interface to be
able to acces IRC even at office (as Shaihulud do for some of us with
CGI:IRC).
Aoineko
This is a *BETA RELEASE* of MediaWiki 1.3.0, after a couple weeks of
testing and tweaking on Wikipedia. Things mostly work at this point, but
installation and upgrade paths may be awkward or broken on some systems
(we don't stress the regular install/upgrade system on Wikipedia since
we do mass runs of piecemeal updates).
Please read the release notes for details of what's changed and how to
upgrade. (Beta1 was not released as a package, but was available from
CVS only. Don't worry, you didn't miss it!)
The easiest upgrade path from a 1.2 MediaWiki install is to set up the
1.3 wiki in a fresh directory, run the web-based installer, and point it
at the same database. BACK UP YOUR DATABASE FIRST! Upgrading the
database may take a while, or may fail on some systems.
Release notes:
https://sourceforge.net/project/shownotes.php?release_id=243741
Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.3.0beta2.tar.gz?do…
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Bug report system:
https://sourceforge.net/tracker/?group_id=34373&atid=411192
-- brion vibber (brion @ pobox.com)
Just a note: NFS version 2 breaks on files over 2gb. Tweaking NFS
settings is cool, but remember to use version 3, not 2, if you set a
version explicitly. This lesson has been brought to you by Painful
Experience University (PEU).
-- brion vibber (brion @ pobox.com)
Hunter Peress wrote
"Please remove timelines from the cvs until it is simplified to work with wiki-tables."
Hunter, so far you've been the only one who dislikes the current concept,
most reactions were favourable or even highly so.
At least five people gave it a try on de: in the past three days and produced workable timelines
with some help of mine.
The syntax is not that difficult to understand.
The length of the document has mainly to do with the number of options that need to be described.
As always flexibility comes at a price: higher complexity.
One has to invest some time to master the finer details, but I believe most people
used an existing example as a template and got away with it.
I'm working on making the syntax as straightforward as possible.
This week I will release an update that will save quite a few lines on some of the existing scripts.
It will never become a no-brainer to produce a fancy new layout,
and finetuning text positions in a crowded chart is a bit of a hassle,
but after my next release (with auto bar positioning and auto image sizing)
adding or correcting an existing chart is certainly within reach of the average editor,
without studying the syntax first.
If someone produces a better solution, (you Hunter ?), I'll be happy to assist in writing a conversion script.
Maybe your only point is that the current syntax stands apart from other wiki syntax?
In that case, I'm afraid I don't think wiki table layout will do much good, as it will just add an extra level of
complexity. But prove me wrong, I'd surely like to test any alternative.
I hope in a years time we can have a fairly complete set of timelines for all major episodes in history.
Without EasyTimeline we would probably have none that could be edited online.
Erik Zachte
The new skin is great and I like it a lot to edit the link colors to my
favorite ones. However I am missing a class for stubs. Was this feature
removed due to performance reasons? I set the "stub value" in the
preferences to 200 chars but it does not change the display?!
Regards
Thomas (Urbanus)
