[prev in list] [next in list] [prev in thread] [next in thread] 

List:       twig-devel
Subject:    RE: [twig-devel] Optimization possibilities
From:       "Greg Ross" <greg () darkphoton ! com>
Date:       2000-03-31 13:53:35
[Download RAW message or body]


	Here's the thing, the php optimizer is still in early beta, I'd rather wait
on specific changes for it until it gets to release, while changing the
increment is easy it does effect large numbers of files and in general I
don't like making far reaching changes without a lot of testing (I had the
mail abstraction running for ~2 months and even it had errors when I
finnally committed it).

							Greg

> -----Original Message-----
> From: Craig Foster [mailto:craig@wiw.org]
> Sent: Thursday, March 30, 2000 11:44 PM
> To: twig-devel@screwdriver.net
> Subject: RE: [twig-devel] Optimization possibilities
>
>
> The optimizers are matched to the releases of PHP4 so you need to
> upgrade to the second beta of
> the optimizer if you are using rc1.  I haven't been real
> impressed with the optimizer yet...pass
> 2 is the only one that really seems to help me.
>
> Why exactly to you want to make a big job later (i.e. a "complete
> php4 optimization") when we can
> do little improvements here and there as we go?  Any speed
> improvement is good in my book.  I
> agree that the incrementing difference isn't a major one, but it
> is something and it is a very
> easy change to make.  I have already made the change in my
> personal installation in all the files
> I use and just have a couple of modules remaining before I have
> changed all of them over.  The
> change in performance isn't huge (usually 0.1 seconds or less --
> average page load time is 0.9 to
> 1.2 seconds or so, excluding mail section), but it is noticable.
>
> Greg Ross <greg@darkphoton.com> said:
>
> >
> > 	I can't reprocude the advantage in php4 but likewise I
> upgraded to rc1 the
> > other day and the optimizer doesn't seem to load under it any more.
> >
> > 	Quite honestly I'd rather leave the $i++'s until we do a
> complete php4
> > optimization on TWIG (I'm sure there will be other things that php4 does
> > differently/better as well) but it really doesn't matter either
> since the
> > 'advantage' should be on the scale of thousands of a second in
> comparison to
> > required/include benifits.
> >
> > 						Greg
> >
> > > -----Original Message-----
> > > From: Craig Foster [mailto:craig@wiw.org]
> > > Sent: Thursday, March 30, 2000 9:58 PM
> > > To: twig-devel@screwdriver.net
> > > Subject: RE: [twig-devel] Optimization possibilities
> > >
> > >
> > > Well, as I said in a previous post, I noticed that this was one
> > > of the changes made by the PHP
> > > Optimizer.  I did test it myself, though, both under php3 and
> > > php4.  I used two different methods:
> > >
> > > (The times listed are from a Pentium 90 w/40Mb RAM, running
> > > linux.2.2.14, apache 1.3.9, PHP4b4pl1)
> > >
> > > 1)  A file that incremented a variable from 0 to 1000 with 1000
> > > lines of $i++; compared to
> > > another with 1000 lines of ++$i;.
> > >
> > >   pre-increment:  0.008693 seconds
> > >   post-increment: 0.011365 seconds
> > >
> > > 2)  for($i=0; $i<1000000; ++$i) {} (28.2513879 seconds)
> > >             vs.
> > >     for($i=0; $i<1000000; $i++) {} (32.7540349 seconds)
> > >
> > > Test 1 is more pure, but I was unwilling to take the time to make
> > > two files with more than 1000
> > > lines just to test this out.  Test 2 allows many more itterations
> > > but has some other factors
> > > present.  Those factors are the same in both tests, so the
> > > comparison should still be valid.
> > > Test 2 is also closer to the usual usage in TWIG.  In both cases,
> > > post-incrementation took about
> > > 15%-25% longer than pre-incrementation on PHP4.  Under PHP3 the
> > > performance of the two were much
> > > much closer, with pre-incrementation having only a very slight
> > > edge.  As I said before, this
> > > performance boost is mainly for PHP4, though it doesn't hurt
> under PHP3.
> > >
> > > Greg Ross <greg@darkphoton.com> said:
> > >
> > > >
> > > > 	Just because I'm curious, what did you use to check if ++$i
> > > was faster?  I
> > > > quickly tossed together a quick script and can't get any
> > > difference between
> > > > the two...
> > > >
> > > > 							Greg
> > > >
> > > > > -----Original Message-----
> > > > > From: Craig Foster [mailto:craig@wiw.org]
> > > > > Sent: Thursday, March 30, 2000 6:48 PM
> > > > > To: twig-devel@screwdriver.net
> > > > > Subject: RE: [twig-devel] Optimization possibilities
> > > > >
> > > > >
> > > > > Yup, I was talking about replacing it everywhere.  It is going to
> > > > > perform the same way, whether
> > > > > it's in a for loop or on a line by itself.  The only time we are
> > > > > going to see any difference is
> > > > > if we try to replace an $x=$i++; with an $x=++$i; or something
> > > > > else where we are looking for what
> > > > > the expression will return (rather than what it will do to the
> > > > > variable $i).  I checked, nowhere
> > > > > in TWIG is that kind of assignment used.  All we have in TWIG at
> > > > > the moment is stand-alone
> > > > > $variable++; expressions (this includes those found in for loops)
> > > > > which are exactly equivalent to
> > > > > ++$variable, except a bit slower.  Personally, I didn't even know
> > > > > that ++$variable or $variable++
> > > > > returned ANYTHING until recently!--I thought they just
> > > > > incremented the variable.
> > > > >
> > > > > Greg Ross <greg@darkphoton.com> said:
> > > > >
> > > > > >
> > > > > > 	No, I re-read it and I belive Craig is suggesting all $i++
> > > > > occurances, not
> > > > > > just single line ones.
> > > > > >
> > > > > > 							Greg
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: m. allan noah [mailto:anoah@pfeiffer.edu]
> > > > > > > Sent: Thursday, March 30, 2000 2:33 PM
> > > > > > > To: twig-devel@screwdriver.net
> > > > > > > Subject: RE: [twig-devel] Optimization possibilities
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > 	From what I read on the require() page it
> says that it is
> > > > > > > only executed
> > > > > > > > once, how would this effect code like the menu types where
> > > > > it's not in a
> > > > > > > > loop but gets executed mutliple times?
> > > > > > > >
> > > > > > > > > 2)  Changing from post-incrementing ($i++) to
> pre-incrementing
> > > > > > > > > (++$i).  I noticed that this is
> > > > > > > > > one of the things that the PHP4 Optimizer does, so I
> > > checked it
> > > > > > > > > out and sure enough, pre-
> > > > > > > > > imcrementing is faster (by about 20%-25% in PHP4).
> > > The result on
> > > > > > > > > the incremented variable is the
> > > > > > > > > same, so it shouldn't make a difference in the
> > > operation of the
> > > > > > > > > code.  Again, this difference is
> > > > > > > > > more evident in PHP4, but it exists in PHP3 as well.
> > > On a quick
> > > > > > > > > search we use post-incrementing
> > > > > > > > > some 314 times in TWIG.  I doubt changing this
> would have an
> > > > > > > > > enormous difference, but it couldn't
> > > > > > > > > hurt, especially in loops!
> > > > > > > > >
> > > > > > > >
> > > > > > > > 	We would have to be careful about loop
> logic here (make
> > > > > > > sure we don't start
> > > > > > > > at 1 instead of 0) but I do have to question why
> pre is faster
> > > > > > > than post...
> > > > > > > >
> > > > > > > > 	I think overeall the chances of making more
> problems in
> > > > > > > this case outway
> > > > > > > > the little bit of speed we might get out of it.
> > > > > > > >
> > > > > > >
> > > > > > > i dont agree greg. twig performance sucks. this thing is too
> > > > > damn slow.
> > > > > > > anything that might help is good. also- if you notice
> what craig
> > > > > > > is saying, he
> > > > > > > is not talking about for() loops, but rather all the places
> > > > > in the code we
> > > > > > > just do a
> > > > > > > $i++;
> > > > > > > on a line by itself. ++$i; produces exactly the same result.
> > > > > > >
> > > > > > > allan
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Craig Foster
> > > > > craig@wiw.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Craig Foster
> > > craig@wiw.org
> > >
> > >
> >
>
>
>
> --
> Craig Foster
> craig@wiw.org
>
>

[prev in list] [next in list] [prev in thread] [next in thread]