(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #340643 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=340643 Imported into Bugzilla on 04/20/99 17:09) I'm not 100% sure about this, but I don't see anything else that I can attrbutie it to, and I think I may have seen it before, so... It seems to me that as I download an 11M attachment that someone sent me (an annoyance in the first place, but that's a different issue) that: a) it is pretty slow, perhaps slower than an attachment download should be?? b) it has slowed down my X server significantly. The former I can live with, and should perhaps be treated seperately (though I suspect it may be related). The latter is a major nuissance, as it not only affects my ability to use Netscape, but it also affects my ability to use other applications on my system, which I consider to be a case of "not playing nice", if you will. According to top, both processes (netscape and Xsgi, my xserver) were using CPU at about 30%, and the kernel was also using about 30% (3 thirties being about 100 -- they were all slightly above 30 really). My _intuition_ tells me that the download was doing _lots_ of updates to the X server to re-draw that window (which explains slowness in both netscape and Xsgi), and that was causing was therefore causing lots of IO to happen on the X socket, thus causing the kernel usage. Not being much of an X programmer, though, the above paragraph is pretty much all speculation, and I invite you to take it or leave it as you see fit. I don't think this is only on SGI, as I believe I've seen this before, but I don't get large attachments all that often, so I'm not certain. Cheers, David

tfv to 4.52 assigning to shanjian

Setting TFV to 4.6. This implies that all these bugs will be considered for fix in 4.6, but there is no guarantee that they will be. More triage needs to be done.

This bug should be postponed to 5.0. It does not meet the 4.6 requirement, and fix may be very complicated.

Setting Target Fix Version to 5.0. Assigning to sol. He will evaluate it and either: 1. fix it in 5.x release. 2. resolve it as WONTFIX

I humbly request that this _not_ be marked WONTFIX. This has a significant impact, and while I can see the justification for delaying it, marking it as WONTFIX doesn't seem like a good thing to me. $0.02, David

Moving this over to bugzilla for consideration for 5.0.

David, is this your area?

No, I don't think so. We have no idea if this is going to be a problem in 5.0 anyway, or what the progress window architecture is going to be.

We'll keep this on the radar to check once the progress window architecture is decided upon and implemented. David, do you want me to set the target milestone to be the furthest one (that I can)?

It's kind of silly to assign it to me, but I don't know who to assign it to. For all we know, it won't be a problem.

Why Platform=all, component=backend if the suspicion is that it's (or, rather, that it was) related to xserver activity? Adding to cc. (And are we bringing over all 4.x bugs?)

Not bringing over all 4.6 bugs. Sol asked me to process the bugs assigned to him.

this is silly - this bug should be marked invalid because it is SO unrelated to 5.0...everything this bug deals with has changed for 5.0 except for imap attachments themselves....anyone mind if we just mark this INVALID?

I agree.

Verified invalid.

*sigh* I guess I'll just have to re-open if the same behaviour exhibits itself in 5.0? Do we have any idea when 5.0 will start shipping??

Yes, you should open a new bug if this starts happening, but please realize that about 95% of the code that may have slowed down the X server in 4.x is now GONE...it will probably be an unrelated problem in 5.0 ..as for when 5.0 ships... let's just say that's not even a relevant question at this point :)