3 ms·
I like https://surf.suckless.org https://surf.suckless.org (which uses WebKit) but it seems like every time I use it and leave a window open for awhile, that pr
by jakeogh 3y ago
I like https://surf.suckless.org https://surf.suckless.org (which uses WebKit) but it seems like every time I use it and leave a window open for awhile, that process (WebkitWebProcess) will end up pegging a core for no obvious reason. It's not site dependent, and I think it's when JS is enabled.
- Alifatisk 3y agoLink leads to 404 Do you mean https://surf.suckless.org https://surf.suckless.org ?
- jakeogh 3y agoThanks:)
- pizlonator 3y ago100% probability that the behavior you observe has 0% to do with this function.
- jakeogh 3y agoOh I agree. I suppose I should read https://www.webkit.org/debugging-webkit/ https://www.webkit.org/debugging-webkit/. It's a problem I cant trivially reproduce on command, so (reading your comment above) I wonder how you would approach it.
- londons_explore 3y agoI would just run "sudo perf record" to do a systemwide performance trace, followed by "sudo perf report" and you'll find the function name where it's spending all the CPU cycles. Another option is to just "sudo gdb -p 12345" to attach to the process, then "thread apply all bt" to get stack traces of each thread, and find whichever isn't sat in "wait". That has the benefit you can inspect local variables in every frame etc (for opensource stuff, symbols are usually available automatically via debuginfod). Chromium/blink has much better built in performance tracing things if you can reproduce there - see chrome://tracing/ for tracing internal browser components, or the Performance tab in devtools if you think it is javascript gobbling all the CPU time.
- anthk 3y agoAll webkitgtk4 browsers run the same, from surf to luakit to vimb to midori.
- lloydatkinson 3y agoWhy does it appear to have an awful default font?