Extra super slow browse

Software ART
1

ART 1.8.3 on Manjaro with a reasonably fast computer.

The browse is extremely slow. It’s large directory: 1180 images. The first time after 35 minutes, I had to kill ART when it was stuck at 20%. Cleared the cache through “Preferences | file browser | cache” and checked made sure everything was gone is “.cache/ART”.

I rerun it after that it took 7 minutes. I was using 1.8.2 on the same machine before, it was much faster in the browser: 2 to 3 minutes for the same directory.

Anything I should do to speed this up?

CPU:       Info: 8-Core model: AMD FX-8350 bits: 64 type: MCP arch: Bulldozer rev: 0 cache: L2: 2 MiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 64031 
           Speed: 1948 MHz min/max: 1400/4000 MHz boost: enabled Core speeds (MHz): 1: 1948 2: 1920 
           3: 3539 4: 3274 5: 2452 6: 2680 7: 1685 8: 3909 
Graphics:  Device-1: AMD Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] vendor: Micro-Star MSI 
           driver: amdgpu v: kernel bus-ID: 01:00.0 chip-ID: 1002:67df 
           Display: x11 server: X.Org 1.20.10 compositor: kwin_x11 driver: loaded: amdgpu,ati 
           unloaded: modesetting,radeon alternate: fbdev,vesa resolution: 2560x1080~60Hz s-dpi: 96 
           OpenGL: renderer: Radeon RX 570 Series (POLARIS10 DRM 3.40.0 5.10.23-1-MANJARO LLVM 11.1.0) 
           v: 4.6 Mesa 20.3.4 direct render: Yes 
Drives:    Local Storage: total: 5.46 TiB used: 1.98 TiB (36.3%) 
           ID-1: /dev/sda vendor: Western Digital model: WD30EFRX-68EUZN0 size: 2.73 TiB speed: 6.0 Gb/s 
           serial: <filter> 
           ID-2: /dev/sdb vendor: Western Digital model: WD30EFRX-68EUZN0 size: 2.73 TiB speed: 6.0 Gb/s 
           serial: <filter> 
Partition: ID-1: / size: 2.67 TiB used: 262.65 GiB (9.6%) fs: ext4 dev: /dev/sda3 
           ID-2: /boot size: 973.4 MiB used: 55.8 MiB (5.7%) fs: ext4 dev: /dev/sda2 
           ID-3: swap-1 size: 12.26 GiB used: 2 MiB (0.0%) fs: swap priority: -2 dev: /dev/sda4

Thank you

2

What does “stuck at” mean exactly? I’ve redesigned the file browsing strategy to be more responsive, but potentially slower. But the program should not get stuck, the browser keeps working in the background, and you should be able to continue using art normally in the meantime. If this is not what happens, can you post a video showing the behaviour? Thanks!

3

It was stuck at 20% and there was no more files being written in .cache/ART/data & images

I just re-cleared the .cache and now it works, albeit slowly but it works. I would say it’s about half of the speed of the 1.8.2.

If it happens again, I will record it.

Thanks

4

Yes that’s expected. We are keeping some cores so that you can start working on images while the thumbs keep loading