Zend PHP IDE 5 Beta Review
September 16, 2005
I have been testing Zend PHP IDE 5 beta for the last week. So far I have found some things nice about it and others that make me just sheer away. So far this has been my experience:
Lets start off with the features that are good:
1. Debugging environment lets you switch between PHP4 and PHP5.
This makes it very adequate when you are testing for functionality between the two different versions. If anything letting you know if they will run under PHP4 and PHP5. This is a very nice feature to have!
2. Code Completion runs under PHP4 and PHP5
In the same setting as the debugging environment you can switch between PHP4 and PHP5 to know which functions that you are able to run…
Althoughs omething I have not seen in any PHP IDE is selecting specific versions ex: 4.2.3 and getting a function list. This in itself would make it even better because then you could actually develop specifically for a version of PHP that you are working with in an enterprise environment. Then possibly giving you a warning depending on if you are using a function that will be disappearing or has been renamed to something else in future versions so you can code accordingly thus making your code able to migrate.
3. Project Management
I like the project manager. Since I constantly work with many projects this helps speed up delayed time in finding all of the files and getting all of the type hints that I need. Also along with this they have integrated CVS and SVN.
4. Including databases
They allow you to include databases from an SQL tab by the project management tab. This will allow you to put in the databases that you are using and have more functionality within the development of your program. I can not comment much on this as I haven’t truely used it as of yet but it is a good thing that they allow this.
5. Code Collapsing
Every great IDE has code collapsing, this allows me to take a chunk of code and make it small so it does not need to take up my screen space. It is a very handy feature to have although it doesn’t always work correctly.
6. Analyze Code
This is a handy feature that allows you to see warnings and other items that might be printed out before you even run your code. This has helped me notice some things that I might not have noticed before… However there are flaws definitely when you have a variable created within an oracle function.
Now onto the things that I do not like:
1. Printing Usability
When you go to print a document it puts the name on the top and the page number on the bottom… which is pretty standard. What I highly dislike about it is that when printing it puts a box around your code that is printed to the paper. This makes it so that there is less room for code and more layout than anything. This could be improved by removing the box.
2. Responsiveness
The editor is still very slow in comparison with many other IDE’s. This single handedly makes me want to use a different application.
3. Code Completion
When using loops and such other items when you create something and the drop down list is still showing you can not use the “End” key to move to the end of it. First you have to close the code completion dialog.
Also in this section when creating a conditional statement it doesn’t add the braces until you hit the enter key. Most of the time when I do not see them I add them. This causes a usability problem when I am dealing with that.
4. Preferences Dialog
The perferences dialog does not allow you to size it dependingly. Also on that list, it just is ugly and could be better layed out. Take a look at the firefox ui for a look at better usability.
5. Code Analyzer
This in itself has problems and redflags the while (list(, $vkey) = each($keys)) loop. It tells me that the Array is being used as a booleen type. However the list function is actually the one with the end evaluation.
More issues is it was telling me the value of an array I used was never used… How so?
$tmp = array();
$tmp = explode('-', $psDate);
//0 - year, 1 - month, 2 - day
$clean['date'] = date(’d-M-Y’, mktime(0, 0, 0, $tmp[1], $tmp[2], $tmp[0]));
unset($tmp, $psDate); //clear the temporary values
That function just checks some input before hand and then explodes it into a mktime… Don’t ask :-/
Then another annoyance:
while(ocifetchinto($stmt, $row, OCI_ASSOC)){
//do stuff with $row
}
Tells me $row was used before it was defined when clearly it is being defined in the while loop with that function!
Talk about a major issue, but yet it is an innovative feature 
6. The internal browser.
The internal browser uses IE on windows by default and takes an extreme amount of time to load. This is not a nice feature if it doesn’t work quickly. I could more simply buffer the output of the debugger directly into the browser of my choice.
Overall I think there are still much better alternatives out there. My main choice of product has always been PHPEdit. It does have problems of its own but overall the developers listen to their users.
Oracle and PHP Performance
September 16, 2005
Well strangely enough I have been working with Oracle databases the last 4 months and have been researching on how to speed them up. Currently the business that I am doing it for is running a highly outdated PHP installation (PHP Version 4.2.3 64-bit). However, there has not been a PHP 4 update from HP-UX which is what they are currently utilizing. There is a PHP 5 update but they do not want to break functionality or start a migration to upgrade old programs that may not work.
With that being said here are a few tips of the trade for speeding up your oracle queries:
1. Utilizing ocisetprefetch (oci_set_prefetch)
Setting the prefetch amount can dramatically speed up queries… By default PHP prefetches one row at a time. This is not efficent when selecting more than one row at a time. If you are fetching consistantly above 10+ records set the prefetch to the average amount. This will cause it to buffer in that amount of prefetch so those rows are accessible much faster.
2. Statement parsing ociparse (oci_parse)
In oracle parsing a statement is one of the more intensive operations. When you are utilizing a query, make sure that you parse your statements outside of a loop and utilize binding variables in order to be able to reuse that query. We will talk more about binding variables later.
An example of this is:
$stmt = ociparse($conn, select * from dual where id=:id);
while ([loop condition]) {
ocibindbyname($stmt, ‘:id’, $id);
ociexecute($stmt);
}
This way you are always reusing your parsed statement and are not increasing your loading time.
3. Fetching one row at a time instead of all rows with ocifetchinto and ocifetchstatement (oci_fetch_into, oci_fetch_statement)
While you should realize the amount of memory needed and the unefficency of ocifetchstatement, some people would still like to get all of the records and throw them into an array before moving on to using the information.
An example of this would be:
$stmt = ociparse($conn, 'select id, name, email from users');
ociexecute($stmt);
ocifetchstatement($stmt, $results, null, null, OCI_FETCHSTATEMENT_BY_ROW); //now we have all the rows in one array
ocifreestatement($stmt);
//lets do a foreach to demonstrate more unefficency
foreach($results as $res) {
echo ($res['ID'] . ‘ ‘ . $res['NAME'] . ‘ ‘ . $res['EMAIL']);
}
Now what we actually did there was fetched every single row into one array which makes it have to query all the data before it can return it into that result set, then maximized our memory with fetching all the rows, then we decided to do a foreach which copies that result set to echo out each one. Therefore you have 2 copies of the same array now add that onto the time it takes to fetch that whole result set.
The more efficent way to do this would be:
$stmt = ociparse($conn, 'select id, name, email from users');
ociexecute($stmt);
while(ocifetchinto($stmt, $res, OCI_ASSOC) {
echo ($res['ID'] . ‘ ‘ . $res['NAME'] . ‘ ‘ . $res['EMAIL']);
}
ocifreestatement($stmt);
All better
4. Setting Indexs and giving oracles parser hits towards what you are optimizing for.
When querying information you might want to insure that you will get a fast return by making sure that all of your joins have an index on the joining query. This will infact be the most dramatic factor with getting high speeds out of oracle. Then to make it more speedy you can use parser rules to tell it which plan to use (oracle creates an explain plan to show you which might be the best one and automatically picks on if you don’t… Sometimes it is wrong in picking the best one.
The following you can use to help it choose which optimization plan to use:
/*+RULE*/
/*+ALL_ROWS*/
/*+FIRST_ROWS*/
The first one is what oracle usually does by default. But it can vary between queries, ALL_ROWS should be used if you are going to use everything from a query, if you are limiting the output use FIRST_ROWS. That will help make your query faster as well.
5. Binding variables ocibindbyname (oci_bind_by_name)
Binding variables are one of the nicest things to use. If you use a binding variable it helps with sql injection as the statement is prepared before you are inserting data. No more escaping quotes. However remember about XSS and the others. You still should always check your input so that it is correct.
Binding variables help you parse a regular statement and allow it to be used multiple times, you can also return things into a bind.
