You're right Oscar. Anyhow, as of next week we'll start rewriting our system on LT1.3 . We will benchmark and profile quite a lot as we go, and we'll share our findings/fixes/features with you.<br><br>Thanks,<br>
Ammar<br><br><br><div><span class="gmail_quote">On 4/25/07, <b class="gmail_sendername">Oscar Renalias</b> <<a href="mailto:oscar@renalias.net">oscar@renalias.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just as I thought, you can't remove constants just because they're<br>"slow" without compromising code readability a *lot*. Would you rather<br>see switch() or if() statements where a variable is checked against
<br>proper constant names or against "magic" numbers? I suppose end users<br>and server admins don't really care that much but we as developers do<br>care about these things.<br><br>Now with all said, you can try to edit the file
<br>class/plugin/eventlist.properties.php and remove its contents. It<br>contains a bunch of constants that identify each one of the events<br>generated by the core, and they're not really needed if you're not<br>
using certain plugins. If any of you has the time to benchmark LT with<br>and without these constants defined, please let us know about the<br>results.<br><br>Oscar<br><br>On 4/23/07, Oscar Renalias <<a href="mailto:oscar@renalias.net">
oscar@renalias.net</a>> wrote:<br>> How are you supposed to use global variables in method definition? As in:<br>><br>> function myFunction( $param1 = MY_CONSTANT )<br>><br>> Versus:<br>><br>> function myFunction( $param1 = $can_I_use_a_global_variable_here )
<br>><br>> Does that even work?? Or please clarify what you mean by "global variables".<br>><br>> Oscar<br>><br>> On 4/23/07, Ammar Ibrahim <<a href="mailto:ammar.ibrahim@gmail.com">ammar.ibrahim@gmail.com
</a>> wrote:<br>> ><br>> ><br>> > On 4/23/07, Reto Hugi <<a href="mailto:plog@hugi.to">plog@hugi.to</a>> wrote:<br>> > > Ammar Ibrahim wrote:<br>> > > > I don't like globals as well, they are a bad software engineering
<br>> > > > practice. But if they are faster, I don't care.<br>> > ><br>> > > well, we do. Else we wouldn't do OO programming. sometimes it's worth to<br>> > > sacrifice speed over
<br>> ><br>> > What if the sacrifice is major? we could at least use global variables<br>> ><br>> > > > Benchmark and let us know :) but use PHP5<br>> > ><br>> > > Things you should know and keep in mind during the performance tests:
<br>> > ><br>> > > - most or at least a significiant amount of users have php4 not php5.<br>> > > that's why we provide backward compliance. we won't implement<br>> > > improvements that brake the compliance.
<br>> ><br>> > of course.<br>> ><br>> > > - we are not really interested in improvements other versions than<br>> > > lifetype 1.2 as this is the version we support.<br>> ><br>> > I'm migrating to
1.2<br>> ><br>> > > - inlude_once was replaced with lt_include in 1.2 to improve performance<br>> > > (lt_include does not lead to file access operations on every call -<br>> > > there might be more to it, but that's what I remember...)
<br>> > > _______________________________________________<br>> > > pLog-svn mailing list<br>> > > <a href="mailto:pLog-svn@devel.lifetype.net">pLog-svn@devel.lifetype.net</a><br>> > > <a href="http://limedaley.com/mailman/listinfo/plog-svn">
http://limedaley.com/mailman/listinfo/plog-svn</a><br>> > ><br>> ><br>> ><br>> > _______________________________________________<br>> > pLog-svn mailing list<br>> > <a href="mailto:pLog-svn@devel.lifetype.net">
pLog-svn@devel.lifetype.net</a><br>> > <a href="http://limedaley.com/mailman/listinfo/plog-svn">http://limedaley.com/mailman/listinfo/plog-svn</a><br>> ><br>><br>_______________________________________________
<br>pLog-svn mailing list<br><a href="mailto:pLog-svn@devel.lifetype.net">pLog-svn@devel.lifetype.net</a><br><a href="http://limedaley.com/mailman/listinfo/plog-svn">http://limedaley.com/mailman/listinfo/plog-svn</a><br></blockquote>
</div><br>