Login   Register  
PHP Classes
elePHPant
Icontem

PHP cannot suck less than developer...

Recommend this page to a friend!
Stumble It! Stumble It! Bookmark in del.icio.us Bookmark in del.icio.us

      PHP Classes blog  >  Will it ever Matter i...  >  All threads  >  PHP cannot suck less than developer...  >  (Un) Subscribe thread alerts  
Subject:PHP cannot suck less than developer...
Summary:In nearly all cases, PHP is as awesome, as...
Messages:8
Author:Ignas
Date:2012-05-08 13:12:59
Update:2012-06-10 22:46:54
 

  1. PHP cannot suck less than developer...   Reply  
Picture of Ignas
Ignas
2012-05-08 17:45:44
In nearly all cases, PHP is as awesome, as developer, who writes PHP code.
I believe, what PHP must not include fancy stuff like case sensitive function names, if it affects performance, if it helps performance, then it is ok.
Also, less stuff - less complexity - less mistakes - less to learn.

As for me, I would consider removing everything what introduces performance penalty, and makes code parsing more complicated: leave only <?php and ?>(complexity & performance), remove double quote strings(performance), remove $_REQUEST super-global (security & performance), remove whole PHP Session thing including $_SESSION super-global(security & performance).

That article about why PHP sucks, had some valid points about PHP being inconsistent, my guess is that it's a result of more than one person doing stuff in same field without talking to each-over.
I'm not concerned about that very much, my wish is for PHP to stay away from my code(e.g. Magic Quotes, Register Globals), I can do that on my own, and secondly the performance, I want performance.

  2. Re: PHP cannot suck less than developer...   Reply  
Picture of Manuel Lemos
Manuel Lemos
2012-05-09 07:54:21 - In reply to message 1 from Ignas
I think the performance matters you refer do not the performance of PHP at run time, only parsing. So, if you use a PHP caching extension, and you should, those performance problems do not really affect you.

  3. Re: PHP cannot suck less than developer...   Reply  
Picture of Ignas
Ignas
2012-05-09 11:05:56 - In reply to message 2 from Manuel Lemos
Not exactly. I refereed mostly to parsing performance, but also to execution performance. Simply catching code will not reduce memory your code uses. It also will not optimize it, having couple hundred lines of optional code, which execution is determined by option selected from MySQL database, both catcher and any other PHP optimizer will consider this code as important.
My ideas were also to remove some super-globals and PHP built in session, you cannot cache any of them.

  4. Re: PHP cannot suck less than developer...   Reply  
Picture of Manuel Lemos
Manuel Lemos
2012-05-09 12:24:02 - In reply to message 3 from Ignas
I am not sure which things you mean will avoid significant executing performance hit.

If you mean setting request super-globals, I wonder if you mean to avoid extracting request variables every time, as if you still extract the request variables in all requests, building $_REQUEST super-globals from $_GET and $_POST will hardly spend more memory or CPU, due to the way variables are copied efficiently in PHP.

  5. Re: PHP cannot suck less than developer...   Reply  
Picture of Ignas
Ignas
2012-05-09 20:55:36 - In reply to message 4 from Manuel Lemos
What I meant is just deprecate it and wipe C code what creates $_REQUEST super-global, same for PHP Session, because I don't feel what PHP Session is good enough for serious projects, in fact, it can be a security issue, and for small projects, they can write code to create temporal file and set cookie by themselves.

  6. Re: PHP cannot suck less than developer...   Reply  
Picture of Manuel Lemos
Manuel Lemos
2012-05-20 07:05:04 - In reply to message 5 from Ignas
Right, but what I am trying to tell you is that building the $_REQUEST array will hardly take any noticeable time or RAM given that it is based on the values already set in $_GET or $_POST.

As for session variables, they are not set if you do not call session_start. Also if you do not like the default session handler that stores the session values in temporary files, you can simply register a different session handler and do something different. There are several alternative session handler classes in the PHP classes site.

  7. Re: PHP cannot suck less than developer...   Reply  
Picture of Ignas
Ignas
2012-05-20 21:25:31 - In reply to message 6 from Manuel Lemos
That's where you are very wrong, $_REQUEST contains contents from $_GET, $_POST and sometimes $_COOKIE superglobals. BUT, they are not referenced, basically $_REQUEST can take as much memory as $_GET + $_POST + $_COOKIE TOGETHER!!!
If you for example send a $_POST variable to a server what is around 1MB in size, the memory what server will use if $_REQUEST is on, will be current memory use+1MB($_REQUEST superglobal).

As of php session, I don't see much of a use for them in the first place.

  8. Re: PHP cannot suck less than developer...   Reply  
Picture of Manuel Lemos
Manuel Lemos
2012-06-10 22:46:54 - In reply to message 7 from Ignas
I suspect you are not familiar how variable value copying works in PHP. Let me describe the details so you understand that variable copying does not mean variable memory duplication.

In PHP, variable values are stored in zval data structures. Those data structures can hold any values of any type. Additionally they have a reference counter number.

If you assign the value of a variable to another, PHP will not create a copy of the original variable. It will just increment the reference counter value and both variables point to the same zval data structure.

So, if you followed this explanation, you may now understand that when you have $_POST values that takes 1MB of RAM, building the $_REQUEST array with the same values of $_POST (or other super-globals) will not make PHP take 2MB RAM. The copied array values will just have their reference counters incremented.

As for PHP sessions, if you do not use them, do not call session_start and you will not use more RAM.

Anyway, if you use some other custom session management scheme to track logged users, you may not have any advantage over the built-in session management.