Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

There was a performance problem for file() and file_get_contents() on systems without memory mapping support; this has been fixed in the stable snapshots.

Please give it a try.

Gave it a try.

Didn't work, sorry. As slow as before...

So now im going to make some testings to find out, where the performance loss originates from.

I already localized some strange side effects, wich point to the conclusion, that it is in fact something with the memorymanagment.
The same script, executed as standalone is much faster, than executed within a huge script.

Ill be back with some more accurate bug-report soon.

so long

mir

Still waiting for the feedback of more detailed information.

ok,ok

did some testing and found at least the following behaviour:
i kept track of includ_once times in my script and ran a couple of times the same script, wich includes havily about 300 kB.

While 4.0.6 did this job with an avarage time of 0.4 ms per kB included script, the 4.3.1 and 4.3.2 versions show an increasing amount of time use to include_once the scripts.

Some values

sumsize	avg 406	avg 432
		
0	0,55	0,47
16660	0,54	0,49
32859	3,92	3,65
57138	0,57	0,80
62766	0,46	0,74
83208	0,46	0,77
106302	0,44	0,69
114039	0,56	0,93
119067	0,57	1,17
129474	0,62	1,08
150891	0,90	1,70
161932	1,46	1,74
167775	0,43	0,83
182655	0,42	1,06
209909	0,47	1,63
246752	0,49	1,51
269711	0,42	1,61
330045	0,48	1,85
346306	0,41	1,64


The three bigger values (3.92,0.90,1.46 at the avg406 col) are scripts that do initial executions and db-queries, so we ommit them.
the rest is simple classdefs, no initializing done.

As you can see, the 432 avg times increase with increasing filesize
(the sizes are summed up so 346306 is the full scriptsize that is run)

Can you read anything helpful out of this posting???

ps Testing was done on win98/php-cgi/apache 1.3.20 systemenvironment.

gruss
mir

You need to provide us the same script to test this with.
Just testing on one machine does not give reliable results.

thx for keeping me busy :-)
i will email the zipped script to sniper (6k, ok?), hope you get it going.

dont bother if i'm a bit quiet next days, but i got a daytime job as a social worker, so be patient.
good testing meanwhile.

gruss
mir

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Can't get any performance loss. Might be something wrong
with your code.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

Most likely a dup of Bug #22721; fixed in the latest stable snapshot.

Sorry for being lazy, i will download the latest stable release (this may take about years on my phonemodem...)
and give it a try.
Think the #22721 trace maybe right, it sounds like similar problems.
The last snapshot (26-Mar-03) of win32 php did not solve the problem.
do swedanaja paka

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.