performance of !is_null and is_null in function
With the following function I'm wondering would there be a performance difference using is_null return $result else
$result = str_pad($value, $pad_length,$pad_string,ST
return $result;
In pl/sql I was told not to use the not in or is not equal to operators as there was more overhead. This function will be used on 100K rows are more so the slightest saving will be important.
Tanks in advance.
<?php
both_str_pad($pad_length,$
{
if (!is_null($value)
{//IF ONE
$result = str_pad($value, $pad_length,$pad_string,ST
return $result;
}//END IF ONE
else
{//ELSE ONE
return $result;
}//END ELSE ONE
}
?>
$result = str_pad($value, $pad_length,$pad_string,ST
return $result;
In pl/sql I was told not to use the not in or is not equal to operators as there was more overhead. This function will be used on 100K rows are more so the slightest saving will be important.
Tanks in advance.
<?php
both_str_pad($pad_length,$
{
if (!is_null($value)
{//IF ONE
$result = str_pad($value, $pad_length,$pad_string,ST
return $result;
}//END IF ONE
else
{//ELSE ONE
return $result;
}//END ELSE ONE
}
?>
ASKER
This definitely helps.
I will always be processing csv files. The main reason I want to use is_null is incase I have a complicated function
that may use unnecessary cpu time if called, so if is_null skip it and save cpu time. Another question in relation to performance.
Which has more overhead and why nesting functions like
$result = f3(f2(f1($val1)));
or
$result = f1($val1);
$result = f2($result );
$result = f3($result );
Any other performance increasing tips would be useful.
Input file will always be in.csv and out file out.csv
Thx I added an extra 100 points.
I will always be processing csv files. The main reason I want to use is_null is incase I have a complicated function
that may use unnecessary cpu time if called, so if is_null skip it and save cpu time. Another question in relation to performance.
Which has more overhead and why nesting functions like
$result = f3(f2(f1($val1)));
or
$result = f1($val1);
$result = f2($result );
$result = f3($result );
Any other performance increasing tips would be useful.
Input file will always be in.csv and out file out.csv
Thx I added an extra 100 points.
dplinnane,
are f1,f2,f3....
require, included, or inline code???
are f1,f2,f3....
require, included, or inline code???
ASKER
I have a file called clean_string.php
I have a setup.php file which contains all of my included files.
define(CLEAN_STRING, $_SERVER[DOCUMENT_ROOT]."$
include_once(CLEAN_STRING)
Within clean_string.php I have a bunch of functions for formatting strings.
I have a setup.php file which contains all of my included files.
define(CLEAN_STRING, $_SERVER[DOCUMENT_ROOT]."$
include_once(CLEAN_STRING)
Within clean_string.php I have a bunch of functions for formatting strings.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The reason you were told not to use the "not in" or "not equal" in PL/SQL is that it often (if not always) creates a VERY expensive query. Most DBAs as well as PL/SQL developers find there biggest performance hits from correcting this type of implementation. The amount of logical I/Os that Oracle(sybase, sqlserver, etc) must do on a "not in" (you can also think of this as several "OR"s) on a table of 100K can quickly get into the millions when join to other table(s). You can often solve this DB issue be restating you logic (and therefore the "where clause") as well as using a "decode" in the select.
I dont think your PHP is costing you all that much here. If you truely have to check each and every row which you seem to be indicating that you do, then you will have to call this function for each row of data. Someone might try to claim that you are using extra calls or bytes etc etc. but this will most likely not be your bottleneck.
The two "not in" concepts dont really have the same purpose or implications.
99% of the time a "not in" in SQL is incorrect. However, most of us that create cleints of software to massage data need to ensure that the data is correct and/or with not effect our displays. Therefore, it wouldnt surprise me if you need to call this function 100K times.
ALL THAT being said....
If this code is meant for 100K rows are these rows from a DB table, flat file, or other.
If they are from a flatfile, then so be it... go through 100K rows with this function.
If they are from a DB file, then why dont you use a "decode" (this is an oracle function but most DB have a similar one) and set nulls equal to a specific value like: 0, "", "xxxxxx", " ", or the like.
You are already touching the row and therefore the fielding during the select process so why not handle it there. Hopefully, this will allow your PHP code to ASSUME correct values and therefore not have to call a function to ensure proper data.
As a further thought.....
Should this field in the DB allow nulls and/or be defaulted to something...
This is something to discuss with your DBA and/or the people more involved with your product/code.
Let me know if this helps....
knel