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