The large text document at <http://warp/tools/qa/history/tests/ biggerjoblist.html> lays out in about 1 minute on Windows (fast Pentium II), and over 10 minutes on a Mac (300 MHz 604). In fact, it took so long that I didn't have the patience to wait, though I did verify through MacsBug that it was still doing stuff when I killed it 10 mins after loading the URL.

I think it's a duplicate of #2211. Reassigned to Simon.

I don't think this is a dup of 2211. I was seeing after some optimizations I made to the font handling calls. I suspect that this performance difference is simply because malloc() is slower on Mac, but I have still to investigate.

sujay/elig - another one...compare against Linux too. Though it does look like Mac is hating life :-)

We'll hold off on performance timings until optimization is in.

Changed URL to a file that is almost 1Mb in size, and a more practical test file.

Accepting

Per discussion with RickG, we don't need to consider this a PP bug. Updated the title.

It worries me that such performance differences are not considered platform parity. If we don't at least understand these problems now, then they will be much harder to address in future. The longer they remain, the more rigid the whole structure becomes, and it becomes more difficult to make the kinds of changes that may be necessary to address performance parity issues. I'd like to put this back on [PP].

I'd like QA to do some minimal performance testing on 01/19. I am putting this back on the [PP] list whilst we try to figure out why the Mac is so slow. It is affecting our ability to test properly.

In our (short) discussion with RickG, we concluded that the most important thing during the Platform Parity Push was to have a correct display and the same features on the 3 platforms in order to allow the XPToolkit and XPApp teams to perform their job. Then the persons who are working on platform-specific issues inside the Raptor team (like Don, Patrick and myself on the Mac, or Ramiro et al on Unix) can address long term problems such as performance. The Platform Parity effort is fairly limited in time and it was for us more a question of efficiently allocating the resources that have been lent to us by the other teams during this short period rather than prioritizing the problems on an absolute scale. Performance has always been one of the main goals for the product. Of course if you consider that the performance is so bad that the QA team can't do their job, you can put it back in the PP list but as far as this bug goes, it's about a file that already takes 1 minute to render on Windows: not really an everyday task.

I just tested with the 1Mb file (http://slip/res-lib/morte1.htm) on a 225Mhz. It takes about 30 seconds to render it after a resize but much longer (something like 1mn 30s) to load it the first time. I noticed that this first load goes slower and slower. If you look at the status bar, you can see the 16K blocks being loaded very quickly at the beginning, then at an interval of a couple of seconds around 500K and more afterwards. Amongst possible explanations: - an XP problem where layout re-parses everything for each block - the memory allocator needs to be tweaked on the Mac Still, there is a problem with Raptor because the resize is synchronous and on a file that long, we can't block the machine during the relayout. QA: could you verify that problem on a Window machine and open a bug report if needed?

beppe, can you try Win95. paulmac, try win 98.

I confirm that this problem comes from the memory allocator on the Mac: as we parse the data, we spend more and more time in nsSmallHeapChunk::GetSpaceForBlock(). Simon, did you port on Raptor the memory allocator that you have done for Nova? QA: If you see that the resize of a large document is a blocking operation on Windows too, could you report it in a separate bug report? Thanks.

Yes, I did port the memory allocators from Nova to raptor, but because realloc is almost never called now (since new & delete have no equivalent) then some of those optimizations will be lost. I'm working on this today.

Actually, not only is the re-size blocking on Windows, but the initial load is also blocking. Who should get this bug for Windows?

Kipp is the man. Could you CC me on the bug report? Thanks!

Bug 2498 filed to kipp for windows specific case.

I've checked in the memory allocator changes that are the main reason for this slowdown. I'll leave the bug open until I'm sure that there are no other low- hanging fruit on this one.

Inserting Milestone info.

Setting all current Open Critical and Major to M3

Putting on [Perf] radar.

Taking off the [PP] list. Some of the performance difference may be explained by the different UI behavior between the platforms. Using the public release 2/19 Win32 build on my PPro 200 system it takes about 21 seconds to display the test file (morte1.htm) but there is no feedback a page is loading other than the title of the window changing. Using a debug build from 2/19 on my Mac (a PTPro w/ 266MHz G3) it takes about 32 seconds to finish loading the file but there is continuous feedback (text appears, scroll bar updates/resizes).

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

changing to M4 milestone

Pierre, do you want to own this, and look at it in your performance week?

rickg, can this be improved anymore for 70% Dogfood?

Almost nothing can be done before Sunday. I'm planning to work on it the last week of March (22-26).

Changed target to M5

Changed traget to M6: this cannot be fixed now because Layout doesn't render long texts properly on Mac and Windows.

Layout now renders long texts properly on the Mac (Windows is still broken) and I could do some testing. The page takes about 20 seconds to display on a G3/233: it's better than my old Windows machine but not quite as good as Communicator 4.5 (7 seconds). Anyhow, the original problem ("10x longer to lay out on Mac") has been fixed. Layout is still slower than Communicator to render long files but that's a different story (#4957 assigned to Kipp).

Fixed in the June 1 Build.