Konqueror vs Firefox
David Boles
dgboles at gmail.com
Sat Mar 8 09:15:28 UTC 2008
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
More information about the users
mailing list