Re: Comment on PHP::PHP_Callback

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Obviously, you don't know what you are talking about.
It just takes  
> common
> sense to know beforehand this is going to be slow.

Hrm. I don't know what I'm talking about? Of the last three
major  
sites I've worked on they include Care2.com (40m+ page views
a month  
and 6m+ registered users), Enotes.com (15m+ page views a
month) and  
Digg.com (Top 100 site on the net, 1m+ registered users).
So, please,  
educate yourself before you say that I obviously am an
idiot. Now,  
I'll explain myself a bit more.

PHP cycles are, in fact, the easiest part of your
architecture to  
scale. File storage is difficult, but possible and DB
traffic is a  
huge PITA to scale. Obviously, his package takes more cycles
to run,  
I wasn't arguing that. The point I was making is that PHP
cycles are  
usually the very last thing that a large site worries
about.

I could give two shits less about 5 extra PHP calls in my
code. Now,  
5 extra DB calls are an entirely different story.

- --Joe




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGO1jUh0MUGpYY9OQRAi0jAJ92rtUTcxKpZ3inDoGhOnq3tDPK/wCg
j70U
X2dMIxDzOJBfI4CxbGHHNS0=
=SlBN
-----END PGP SIGNATURE-----

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

On 5/4/07, Joe Stump <joejoestump.net> wrote:
> > Obviously, you don't know what you are talking
about. It just takes
> > common
> > sense to know beforehand this is going to be
slow.
>
> Hrm. I don't know what I'm talking about? Of the last
three major
> sites I've worked on they include Care2.com (40m+ page
views a month
> and 6m+ registered users), Enotes.com (15m+ page views
a month) and
> Digg.com (Top 100 site on the net, 1m+ registered
users). So, please,
> educate yourself before you say that I obviously am an
idiot. Now,
> I'll explain myself a bit more.
>
> PHP cycles are, in fact, the easiest part of your
architecture to
> scale. File storage is difficult, but possible and DB
traffic is a
> huge PITA to scale. Obviously, his package takes more
cycles to run,
> I wasn't arguing that. The point I was making is that
PHP cycles are
> usually the very last thing that a large site worries
about.
>
> I could give two shits less about 5 extra PHP calls in
my code. Now,
> 5 extra DB calls are an entirely different story.
>

I think we're getting into the realm of the C hacker here
and I'd like
people to take a step back.

Joe's point is very well made. Remember the fallacy of
Premature
Optimization. It is always best to write code in a
maintainable and
usable way and *then* profile and optimize. If there are
code and
packages that make your life as a coder simpler, use them.
Remember
also the rule "Computer time is cheaper than coder
time".

Not only is trying to keep this package out of PEAR due to
"too many
cycles"  case of extreme premature optimization
(optimizing code you
haven't written yet by limiting the tools you can use) but
it is also
against the grain of what PEAR is. If we were worried, at
the bottom
level, about CPU time we wouldn't have or use PEAR at all.
PEAR has
packages which abstract and make your life easier as a
coder. They
*do* and *will* slow down your code. Period. You can always
write
faster code by loading one small, optimized file which does
only
exactly what you need.

It is important to remember that unless the code/algorithm
is written
horribly the CPU time is not what you should be worried
about in
almost all cases. I/O is almost always the biggest slow-down
in an
application. Reducing CPU time is far less important than
reducing
I/O. If your I/O is omtimized then you profile your code and
find ways
to reduce CPU. Not using PHP_Callback is not likely to be
one of your
big offenders.

This package looks like it solves a real problem in a unique
and
elegant way. I would be for including this package in PEAR.

-- 
Justin Patrin

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php

Le 4 mai 07 à 18:01, Joe Stump a écrit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>> Obviously, you don't know what you are talking
about. It just  
>> takes common
>> sense to know beforehand this is going to be slow.
>
> Hrm. I don't know what I'm talking about? Of the last
three major  
> sites I've worked on they include Care2.com (40m+ page
views a  
> month and 6m+ registered users), Enotes.com (15m+ page
views a  
> month) and Digg.com (Top 100 site on the net, 1m+
registered  
> users). So, please, educate yourself before you say
that I  
> obviously am an idiot. Now, I'll explain myself a bit
more.

Because the companies you worked for can afford more
hardware,  
doesn't mean everyone can.
Because hardware can sometimes cope with your programming
mistakes  
doesn't mean everyone should make programming mistakes.

> PHP cycles are, in fact, the easiest part of your
architecture to  
> scale. File storage is difficult, but possible and DB
traffic is a  
> huge PITA to scale. Obviously, his package takes more
cycles to  
> run, I wasn't arguing that. The point I was making is
that PHP  
> cycles are usually the very last thing that a large
site worries  
> about.
>
> I could give two shits less about 5 extra PHP calls in
my code.  
> Now, 5 extra DB calls are an entirely different story.

That's because you are not the average Joe. The average Joe
(or the  
average me for instance) cares about his code performance,
as much as  
he cares about his database performance and his girlfriend
cycles.  
When you tell people "hey look there is this new way to
use  
callbacks", they will start using it and polluting
PEAR, just like  
they did with PEAR_Errors. This is what I would like to
avoid.

Now, I think we can stop the discussion here since there has
been  
enough arguments pro and against this proposal.
The rest is just 'Look, mine is bigger than yours'.



--
Bertrand Mansion
Mamasam
Work : http://www.mamasam.com
Blog : http://golgote.freeflux.n
et

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub
.php