Opera 45.0.2552.812, latest Arch Linux.

Right from start Opera burns CPU with poll() loop as shown by strace: [1]

It is always 2 file descriptors, in this case, 110 and 117.

Looking at it closer, strace shows backtraces for each EAGAIN'ed recvmsg: [2]

Looks like it has something to do with X server interaction.

Checking those descriptors here: [3]

Closing those descriptors via gdb results in Opera SIGSEGV.

Always reproducible, even with clean profile and no extensions.

Is there any option how to save my CPU cycles?

Thanks.

[1] https://gist.github.com/a8d11ac5477982128525f51f11d3ca4d
[2] https://gist.github.com/d32b99483a5c236cbd92aa38e586741f
[3] https://gist.github.com/5aee3ef7d487a67e23d7d001f2c46ea6

Same with v46.0.2597.39.

Same with v46.0.2597.39.

Still applies to v46.0.2597.32.

Arch Linux, Opera v46.0.2597.32.

v46 update broke HiDPI autodetection. Things just get tiny on HiDPI screen. Also, "--alt-high-dpi-setting" option does not work anymore.

"--force-device-scale-factor" works, however, rendering UI usable, but icons are upscaled and look weird, and it seems that upscaling applies to fonts too.

How this could be fixed? Any additional info needed from me?

@avl, in Task Manager, "Browser" process consumes 15 to 25% of CPU.

Still applies to v46.0.2597.26.

Same with v45.0.2552.898.

Again, same applies to Chromium 59.0.3071.86, but to less extent. strace shows the same picture, but recvmsg fails with EAGAIN once per several seconds, thus CPU load is minimal. For Opera, recvmsg returns EAGAIN lots of times per second, and CPU load is noticeable.

So, this has something to do with common engine code, likely, interaction with X server.

Same with 45.0.2552.888.

Same applies to 45.0.2552.881.

Same applies to Chromium 58.0.3029.110. The only difference is that EAGAIN arrives more rarely (once per several, up to 10, seconds), thus CPU is not used that high as by Opera.

So, it has something to do with engine.