Sponsored Content
Top Forums Web Development Opera on the Rise? FF in Decline? Post 302307949 by Neo on Thursday 16th of April 2009 05:06:59 PM
Old 04-16-2009
Quote:
Originally Posted by Housni
But I've found that FF takes up massive amounts of CPU even without a single flash object running in it. It also behaves badly on sites that are AJAX intensive...such as gmail, for example
Agreed. I have seen FF3 scorch the CPU when no flash is running.

Then again, one of the issues with tabbed browsing is that if we are not careful, we can have 20 or more tabs running before you know it, each running something "hot".....

Frankly speaking, after running Opera for a week or so, I have scorched the CPU on my laptop on at least one occasion. So, I am not 100% sure if the problem is isolated to FF3, as I am starting to see a similar condition on Opera Smilie (on both Windows XP and Mac OS X)
 

4 More Discussions You Might Find Interesting

1. UNIX Desktop Questions & Answers

The OPERA browser

I have just seen someone using the OPERA browser - it looks quite good and seems to have a friendly GUI. Can I get this for UNIX(Solaris 8 is my OS)??? Does anyone have this installed on their UNIX workstation?? How is it performing?? All comments and advice is welcome!! (1 Reply)
Discussion started by: Kanu77
1 Replies

2. AIX

lvm_queryvg call does not work properly and results in a sudden memory rise.

On AIX 5.3 host, the lvm_queryvg call does not work properly and results in a sudden memory rise. This is happening on one particular host and the call works fine on another host. Is this a known issue and is there any patch available for this? (0 Replies)
Discussion started by: sandiworld
0 Replies

3. Solaris

Opera 9.5 for Sparc

Has anyone gotten Opera 9.5 to work? I'm using Solaris Sparc 5.10. The browser is unusable. It crashes even when viewing Opera's Desktop Team blog. I've asked Opera about this, but no reply. I've never been able to get the 9.5 betas to work either. From one Opera user's blog, I don't see any... (0 Replies)
Discussion started by: cooldude
0 Replies

4. Solaris

Sudden rise in heap memory of a process

Hi, There is a abrupt memory rise observed for a process on solaris. When the process is started the memory is around 268 MB and is stable for a day. Then suddenly the memory increased to 4364 MB. Below is the pmap -xs output for the process (only for heap) Address Kbytes ... (1 Reply)
Discussion started by: Nidds
1 Replies
iopause(3)						     Library Functions Manual							iopause(3)

NAME
iopause - check for file descriptor readability or writability SYNTAX
#include <iopause.h> int iopause(iopause_fd** x,unsigned int len, struct taia deadline,struct taia stamp); DESCRIPTION
iopause checks for file descriptor readability or writability as specified by x[0].fd, x[0].events, x[1].fd, x[1].events, ..., x[len-1].fd, x[len-1].events. If x[i].events includes the bit IOPAUSE_READ, iopause checks for readability of the descriptor x[i].fd; if x[i].events includes the bit IOPAUSE_WRITE, iopause checks for writability of the descriptor x[i].fd; other bits in x[i].events have undefined effects. iopause sets the IOPAUSE_READ bit in x[i].revents if it finds that x[i].fd is readable, and it sets the IOPAUSE_WRITE bit in x[i].revents if it finds that x[i].fd is writable. Beware that readability and writability may be destroyed at any moment by other processes with access to the same ofile that x[i].fd refers to. If there is no readability or writability to report, iopause waits until deadline for something to happen. iopause will return before dead- line if a descriptor becomes readable or writable, or an interrupting signal arrives, or some system-defined amount of time passes. iopause sets revents in any case. You must put a current timestamp into stamp before calling iopause. IMPLEMENTATION NOTES
The current implementation of iopause uses the poll function if that is available. On some systems, poll needs to dynamically allocate ker- nel memory; when not much memory is available, iopause will return immediately, and will report (often incorrectly) that no descriptors are readable or writable. This is a kernel bug, and I encourage vendors to fix it. If poll is not available, iopause uses the select function. This function cannot see descriptor numbers past a system-defined limit, typi- cally 256 or 1024; iopause will artificially pretend that those descriptors are never readable or writable. Future implementations of iopause may work around these problems on some systems, at the expense of chewing up all available CPU time. Both poll and select use relative timeouts rather than absolute deadlines. Some kernels round the timeout down to a multiple of 10 mil- liseconds; this can burn quite a bit of CPU time as the deadline approaches. iopause compensates for this by adding 20 milliseconds to the timeout. SEE ALSO
select(2), poll(3), taia_now(3) iopause(3)
All times are GMT -4. The time now is 08:16 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy