2011/1/4 Roan Kattouw <roan.kattouw(a)gmail.com>
Just from looking at the LST code, I can tell that it
has at least one
performance problem: it initializes the parser on every request. This
is easy to fix, so I'll fix it today. I can also imagine that there
would be other performance concerns with LST preventing its deployment
to large wikis, but I'm not sure of that.
Excellent, I'm a passionate user of #lst extension, and I like that its code
can be optimized (so I feel combortable to use it more and more). I can't
read php, and I take this opportunity to ask you:
1. is #lsth option compatible with default #lst use?
2. I can imagine that #lst simply runs as a "substring finder", and I
imagine that substring search is really an efficient, fast and
resource-sparing server routine. Am I true?
3. when I ask for a section into a page, the same page is saved into a
cache, so that next calls for other sections of the same page are fast and
resource-sparing?
What a "creative" use of #lst allows, if it is really an efficient, light
routine, is to build named variables and arrays of named variables into one
page; I can't imagine what a good programmer could do with such a powerful
tool. I'm, as you can imagine, far from a good programmer, nevertheless I
built easily routines for unbeliavable results. Perhaps, coming back to the
topic..... a good programmer would disrupt wikipedia using #lst? :-)
Alex