At 2003-08-16 23:05 +0000, Curt Zirzow wrote:
>* Thus wrote Binay Agarwal ([EMAIL PROTECTED]):
>> Hi everybody,
>>
>> Lot of places in manual i came across using "ereg_replace" or "ereg" is very
>> resource intensive and hence its better to use "preg_replace" or "str_replace" or
>> "strpos" if they do the jobs.
>>
>
>I believe the use of ereg_replace in the samples you see is mainly
>due to the fact that not until recently has preg_* function been
>enabled by default. So it would make sense for the manual to use
>examples with ereg_* functions so the example would be garuenteed
>to work.
Plus that the ereg functions implement the old-fashioned
Unix regular expressions and preg the Perl variation.
Of course the Unix version (dating from around 1975 or
even earlier) is much more standard than the Perl version
of around 1990 (?).
>I would even suggest someone to use str_replace over preg_replace.
Yes.
>The fact being that anytime you call a regular expression function
>it has to compile the expression and then apply that compiled
>expression to the string. Where the str_replace is directly
>manipulating the string which is quicker than preg_replace's
>method.
Compiling the expression is a (time) linear
process so it doesn't matter.
>The only time the overhead is acceptable would be when
>you're string is not entirely known, so:
>
> preg_replace('foo-bar-', '', $str);
>
>Can simply be changed to:
>
> str_replace('foo-bar-', '', $str);
>
>The expression, however:
> preg_replace('foo-\w+-', '', $str);
>
>Can't be done with str_replace.
>
>As for the resouce usage vs. ereg and preg, I believe it is
>entirely the nature of the libraries that they use. I don't think
>the source of the functions will reveal too much.
The real problem is that ereg functions probably
allow more recursion to take place than preg
(which was designed long after the disadvantages
of ereg where known).
In computer science it is never considered a
problem as long as a process is (time) linear,
so that when the input is of size n, the time
taken is n times a constant factor. Just wait
18 months and the average CPU is twice as fast.
What can be a problem however is when a proces
is not (time) linear but for example quadratical
in the time needed for input of size n. So the
time to handle an input of size n is n^2 (times
a constant). This is also no problem when n is
small, but when n gets to be 100 or 1000, the
time consumption gets to be 10,000 or 1000,000
which can become problematical.
The normal str functions are generally (time)
linear in order. The ereg functions can be
recursive and therefore quadratical (or worse)
in nature and the preg functions seem to limit
this because of how they are defined.
But I'm sure that when one would compare the time
taken by the normal str functions to that of ereg
functions given the same simple regular expression
(just a string) that the ereg functions are not
more than twice as slow (and therefore of the
same order) and won't become of quadratical order.
Anyone care to try this out? Just use quite a long
string to search in and execute the search a 1000 or
1000,000 times to make it measurable. Could be a nice
school project...
Greetings,
Jaap
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
