can you trace it back to a specific funtion?

I think I identified the slowliness factor: big mails.

Testing with Apache 1.3.14 on NetBSD with PHP 4 latest snapshot and imap 2000 final on a PPro 200/256MB, mail server being POP3 and on the same LAN than the Web server:

 - mailbox with 15 small (< 10KB) messages: 15 seconds to load
 - mailbox with 4 messages and one being over 1MB: 30 seconds to load

When I test this on Apache 1.3.12 with PHP 4.0.3pl1 as module, IMAP server on the same LAN, on a Celeron 500/256MB:

 - mailbox with 4 messages and one being over 1MB: 3 seconds to load
-> very fast, the slowliness can't be identified when PHP is loaded as a module.

It seems like the imap lib is taking a lot of time to parse a _big_ message, that can be seen in CGI mode, not in module mode (at least for Apache).

I was wrong with imap_sort() being slow, it didn't change anything with a small mailbox, therefore with a big message, it increases a bit more loading the mailbox:

 - mailbox with 4 mails and one over 1MB: 30 seconds
 - same mailbox, imap_sort() commented out: 20 seconds.

In all these tests with PHP as CGI, it seems to take 3MB of RAM, no more, even with big messages.

I tested all these with IE5 and latest Mozilla which both handle HTML tables correctly unlike Netscape 4.x

ok, I finally traced it back to a specific function:

I use both imap_header() and imap_fetchstructure() functions for my webmail client:

 - imap_fetchstructure() commented, I get back to 15-20 seconds with my 4 mails' mailbox and one > 1MB.
 - imap_header() commented, I get 27 seconds (close to 30 seconds) with the same mailbox.

ok, to summarize this :)

=> With "big" mails (> 1MB or so), imap_fetchstructure() is very slow in CGI mode.

Well, no, I'm disappointed, I just tested with a 6 mails' mailbox which of 3 are 1MB large:

 - normal code: after 2 minutes, php error: "max. 30 seconds time exceeded at line 44" -> imap_fetchstructure()
 - imap_fetchstructure() commented, 1 minute
 - imap_fetchstructure() and imap_sort() commented, 45 seconds

I know MIME parsing is really a hard job, but why is the CGI version so much slower than the Apache module version ? Any idea ?

I tested imap_fetchstructure() with the
pear/Benchmark/Timer.php package

with the following code:

[...]

$timer = new Benchmark_Timer;
$timer->start();
$timer->set_marker("42");
$struct_msg = @imap_fetchstructure($pop, $mail);
$timer->stop();
$profiling = $timer->get_profiling();

[...]

Here're the results with PHP latest snapshot as CGI on a
PPro200, 256MB, and POP server being local, Apache 1.3.14,
PHP binary is 2MB large (without debugging symbols).
I load one mail at a time and see how long it takes for
imap_fetchstructure() to parse it depending on the size:

- 1KB, no attachment: 0.011 sec
- 78KB, no att: 0.225
- 68KB, 1 att: 0.225
- 1428KB, 1 att: 4 to 7 seconds !

With PHP loaded as a module, it's immediate (< 1 second)

During the test, the load was 0.6 and I tested several times
to be sure of the results.

So, to sum up:

imap_fetchstructure() is slow with big mails when PHP is
compiled as CGI.

Does this problem still occur with the 4.0.6, the latest RC(http://download.php.net/~zeev/php-4.1.0RC3.tar.gz) or the latest CVS?

I can't reproduce this with 4.0.6, latest CVS or 4.1.0RC3 as they don't compile on my machine. Bug already reported on php-qa@.
However, the machine was upgraded, although it's still running NetBSD 1.5, Apache 1.3.20 and PHP 4.0.5 as CGI, it's now an Athlon 800 instead of a PPro200, and it's quite fast.

However, bug still exists as PHP as module is faster, and the IMAP code hasn't changed quite a lot since last year.

Does this error still occur with the lastest (CVS) version?

I don't have a slow machine to test this anymore. We switched to a more powerful machine where the problem is harder to pinpoint.
Therefore, I guess the problem still remains as the IMAP source code hasn't changed since (besides additional features).
I won't be able to test this bug anymore as I won't have time for this.

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.