Quote:
Well I'm sorry you aren't correct, where are you getting this information from? ....infact a recent quote from Jason
Jason? I know him as Jagerman.
He wrote:
Quote:
GT::Template version 2.000 saw the introduction of parsing templates into Perl, as a speedup. We were expecting that the first parse would be slower, since we have to parse _and_ run the code, but much to our surprise, parsing and then running the code was actually faster than the parsing in version 1
Yes, Jagerman is right. GT::Template v2.0 is several times faster than v1.0, because of compiling.
And Yes Paul, I'm aware about compiling the templates, and that compiled templates are Perl executed.
And Not, this does not mean, that I'm not right.
Quote:
where are you getting this information from?
And I'm getting this information from my experience. I did profiled Links 2.0 (not right LSQL, but will do for LSQL too if needed).
I wrote,
"
my experience with Links profiling is, that most of the time is spent in the template parsing, so the SQL queries are not the point, where we get considerable performance loss, compared to the full execution time (of course IMPO)".
I profiled Links v2.0, so it is proven for me, that template parsing takes the most time in the LSQL page display process, compared to the full execution time. I did not profiled LSQL yet, but I can be sure, if somebody did, he found that the template parsing still takes the longest time in LSQL 2.x.
I will do the LSQL profiling as I will reach the point, when I want to improve speed, and I have to do some optimizing. Later.
Quote:
That is absolute rubbish.
It seems rubbish is, what you know about the template system.
Quote:
But there is no reason to move it into a plugin, the existing globals found throughout the forum work perfectly well.
There is good reason. Globals are slower, than a code which is inserted at the right point. Not noticeable slower, but slower. If I move into the plugin, I save multiple query time, the global does, and save the extra code I would need to install that global. It it is placed in the plugin, then the plugin is installed, so the feature what was global, too.
When executing a global, you do the following:
1) compile the template if it was not compiled
2) execute the compiled template code
3) continue printing text until there is a template tag.
4) execute, or print what the tag contains (even a global)
5) go to step 3) until the end of the code
As you see, each tag stops execution, executes the tag code.
The real overhead is the database connection and those queries, which may are executed several times, for each global, while if the plugin is doing good job, and re-use query data, then it is more efficient.
However, when we are
comparing time overhead to full execution time:
1) Globals overhead taken from multiple queries, is really not much, when comparing to case, if we do in a plugin (but will be a slight difference). Globals should not take too much time from full execution time.
2) Templates takes a lot percent of from full execution time. No matter that they was compiled and executed in Perl.
3) Not really belongs here, but I also notice the
clean_output (which is executed for each page).
I suppose that, there is a noticeable time taken in the clean_output, which is executed for almost each template page. We discussed already with Alex about that. This will be proven only, when the LSQL profiling was done. A would not want to predict how much percent the clean_output execution takes.
Profiling always brings some surprises, we did not ever thought!
BTW: If anybody has profiling data about LSQL, please send me. I would be interested in it!
Best regards,
Webmaster33
Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...