Nathan Grennan wrote:
David Boles wrote:
Nathan Grennan wrote:
David Boles wrote:
Okay. Still trying to understand this.
Is the 'fsync' problem, the differences for you, with the same page?
I ask because so many pages are so very active today. If it is a
page, or several? If you would like I would try them from here.
It doesn't matter so much about the page. Any page will do. From my
limited testing it did it on every page. It was like click bookmark,
page loads, gets to end of loading, eight fsyncs within a second of
each other. Click another bookmark, page loads, gets to end of
loading, eight fsyncs.
The page, http://www.news.com.au/, that was in the beginning of this
thread, is in IMO a pig of ads and Flash. And without the
'protection' of the two extensions that I mentioned it did bog down
my Firefox for a second or two. Somewhat but not much. But nowhere
near as the OP, and others, talked about in their posts.
I honestly do *not* see the halts that you, and others, nor the
other things many are writing about here. And this was using Firefox
3.0bpre5.
I am puzzled. Unless it could be differences in Internet access or
differences in hardware perhaps? Or a combination of differences in
both?
You only see this end you do intensive i/o stuff. The easiest
example, dd if=/dev/zero of=testfile bs=2M count=1024. Then start
clicking through pages in Firefox. It will almost surely become
unresponsive, and I don't mean just you can't click on anything. I
mean you switch to another window and back, and it won't even redraw
itself. You will now just have a big grey window where firefox used
to be, till it comes back. Which sometimes it comes back within a few
seconds, but sometimes it won't come back till the write of other
program, like dd, is completely done. You can also see this with
VMware Workstation while creating guest images, or doing heavy guest
i/o, like say installing a bunch of updates in a Windows guest. You
can see this with virt-manager and creating a new guest image. You
can see this with kernel compiles.
Well now this, what you are describing, sounds more and more like
hardware
limitations instead of some specific Firefox related problem.
I would think that any kind of intense disk activity or CPU usage would
cause programs to stutter as well as other things.
Perhaps your view of this situation is too narrow?
I don't care if it writes the data, but it is completely blocking the
interface when doing it, which is bad bad bad in my opinion.
Someone left a comment on my bug pointing to another related bug,
https://bugzilla.mozilla.org/show_bug.cgi?id=417732
Also the next e-mail in the thread hits on the same topic, use of sqlite.
I have read your bugzilla report and what you are seeing is, I think,
quite possible. However one of those that made a comment spoke of 7KB and
12 KB writes to the Firefox sqlite data bases. 7KB or 12 KB? If writing
something that small is causing your problems I would think that you have
a much larger problem someplace else.
Your email for example, this one that I am replying to here, is
approximately 7.18 KB in size. The mozilla-firefox.png, the Firefox icon
for the menu, is 6.1 KB. I would not consider those to be large.
Best of luck finding a solution to your problem.
--
David
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
