https://bugs.kde.org/show_bug.cgi?id=398908
Brennan Kinney <polarathene-sig...@hotmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |polarathene-signup@hotmail.
| |com
--- Comment #44 from Brennan Kinney <polarathene-sig...@hotmail.com> ---
Hi, was sent here to share my own experiences.
Manjaro KDE, Dolphin 19.08.2. Breath theme, but Breeze is the Application
style/widget. I have noticed this problem for the past year. Hardware is an
Intel i5-6500 CPU with 32GB RAM and an SSD disk. nvidia proprietary drivers are
in use, X11.
My workaround is to copy the breadcrumb paths to a new Dolphin window,
recreating my tabs and closing the old Dolphin window to free the
memory(closing tabs alone does not free anything apparently). Rinse and repeat.
The worse case I've experienced was up to around 4GB, may have been more I've
not kept track. Usually I notice Dolphin become sluggish(single core/thread of
CPU is pegged at 100%) from interactions such as scrolling through the main
content pane(jittery/jumpy or low framerate paints, window only, the window
itself can be moved smoothly with kwin wobbly window effect no issue). Changing
tabs, closing tabs, right click context menu on the breadcrumb location for
copying, all of these I recall inducing the 100% CPU core load for several
seconds(length of delay depends on memory consumption, can be closer to 10
seconds).
I believe with the recent 19.08 applications update, dockers overlayfs mounts
began appearing again for some reason. I only mention this because someone else
here asked about Docker, their visibility is probably a regression that should
be raised in another bug report and unrelated to this issue. I've experienced
it without running the Docker daemon.
Probably the time I noticed it the most active was when I had about 5 tabs in
one window open, rarely interacting with them, but doing heavy editing of some
files(fontconfig specifically). At one point, I may have been actively deleting
files(cache) that I believe one tab covered. The deletion iirc was via CLI, but
Dolphin would visibly update to represent files being added/removed if I had
that tab open. I recall this iterative approach generating 20-40-ish files each
time I modified/saved my font config files, I'd clear the generated cache, and
open up a web browser(firefox) which would rebuild the cache, or if the cache
existed add about 9 items(1 per process I think). Must have gone through
thousands of those cache files.
Someone brought up Gwenview. In the past I would "disable" a display(dual
monitor setup), without physically powering it off, but as it's DVI connection,
it couldn't be done via software command either, so I fullscreened an solid
black image with Gwenview. Usually because it was at night and I wanted to
watch something on Netflix without the other display being distracting. I can't
recall how long it'd take, few hours to a day perhaps, but Gwenview
responsiveness at leaving the fullscreen state would be very slow(10 second or
so). So the other commenter may be onto something related there as both Dolphin
and Gwenview are likely to share some KDE Frameworks lib?
While the active development and file tree updates example above with
fontconfig might sound like it's related only to that sort of activity. I've
left a Dolphin window open/idle and gone to sleep, 8 hours later 1GB more of
memory was allocated to it. I've also witnessed via ksysguard Dolphin memory
climbing over the course of an hour, but I don't recall it being constant or a
fixed amount(not that I properly measured this). All I know is it can grow with
no interaction, but file updates/refreshes may be worth looking into?
As for my typical usage, I usually only use one virtual desktop, but sometimes
I do use multiple, I've not done any observations if that makes any difference.
I tend to have one or two windows open, especially if I use multiple virtual
desktops, tabs average 3-5, rarely more than that per window. Tabs are usually
project directories(developer), or downloads directory(I don't download that
much, but I haven't been housekeeping(currently it states 14 folders, 97 files,
71MB). Baloo is enabled(I've also noticed high CPU activity recently when using
the default search feature, no new results for some time but the CPU usage
remained at 100% for a full core until I closed the search, KFind tends to work
better for me and doesn't exhibit issues like that).
I also use sftp in Dolphin for accessing a remote server, Kate may be open with
some files from that which were opened via Dolphin(usually drag/drop from
Dolphin to Kate). Current Dolphin window is at 1.2GB and has been fairly steady
on that with 3 tabs. The most active tab in that window would be the sftp one.
Been open for a day or so, on virtual desktop 3 atm, and most of my activity
has been with Chrome and Kate(editing some remote files). I'm a little
surprised as it seems a bit more tame in memory usage/growth. Perhaps another
possibility could be when the browser, steam or a torrent program is performing
a download over multiple hours(8Mbit connection), and a tab is open like
"Downloads" having it's metadata updated frequently as the transfer progresses?
I have switched off previews in Dolphin as of late, possibly after the
fontconfig work where I frequently recall having frustration with this issue.
Info panel is still there, so perhaps you're onto something about that being
the main cause of memory growth. At 1.2GB for the current window mentioned,
there is about a 500-1000ms delay changing tabs and context menu on
breadcrumbs(it became faster to respond after the first right click), scrolling
is fine for the file tree(tree view, some folders expanded, states 18 folders
61 files for the sftp tab) , it's mostly fine scrolling up/down repeatedly on
the left panel with my list of places, remote, devices(includes two docker
overlay items atm) and removable devices, but occasionally freezes for a moment
before jumping to the scroll position, it continues to switch between smooth
and not updating to mouse/scroll position for about a second(just noticed this
seems to happen based on the horizontal position of the cursor, absolutely fine
if dragging over the left pane, but crossing over the scrollbar element is what
hits high CPU load on a core/thread at around 80% briefly).
--
You are receiving this mail because:
You are watching all bug changes.
