Can you try to point these to an empty folder (create an emtpy folder somewhere in your file system and set the paths for flatfield and darkframe in preferences to this folder)? For reference
I don’t know whether it will be substantially faster. It’s just about excluding a possible culprit
changed C:\Program Files\RawTherapee\5.3 to D:\testing for both instances.
Where D:\testing is an empty, freshly created directory.
No changes. Same startup time. 
But did you read this (previously posted)?
Changing those two dirs doesn’t change anything in RT’s startup time.
I can use RT several times with a reasonable (but still slow for a small program on a fast machine) startup time of about 8 seconds, and then suddenly it falls back to 50 seconds startup time…
Yes, I read this. I’m mainly on Win7 and the startup time of RT is between 3 and 7 seconds. 3 seconds when using METM (less gui at startup) and 7 seconds when using SETM (gui creating empty editor at startup). I agree that this could be faster!
I’m on Win10 with an old i3 Dual core 2.9GHz, 8GB Ram and the startup time is approximate 12 sec.
I keep on digging into my system, to figure out why/with what RT is so busy. 
Another thing I noticed, when RT is finally started, when browsing to a directory with a number of large (500MB or bigger) TIFF files, it takes a very long time before all the TIFFs are being processed/displayed, even after the ‘loading thumbnails’ message has disappeared and not all the TIFFs are already displayed.
RT is very busy with ‘Hard Faults/s’ aka paging memory. Numbers vary between 70-120 Hard Faults/sec, while at the same time Disk I/O is very low, CPU Usage is only 1-2% and committed memory usage of RT is even <2GB of RAM.
I have the option “serialize read of TIFF files” checked; but it doesn’t seem to make much difference (?)
Is there maybe a memory option for RT to use the available memory in my system (24GB RAM) instead of paging so (too?) much?
Normally I only get this kind of paging (large amounts of Hard Faults/s values) activity when I load >2GB of graphic files into PS CC 2017 with lots of layers and all the internal memory has already been used by PS CC 2017 and there is no ‘Free memory’ left anymore.
But in this case; where RT is keeping the paging memory counter busy, there is more then 20GB of RAM free!
Just an additional question: why does rawtherapee open that many handles to an empty directory?
I thought of starting the Task Manager before starting RawTherapee and checking the CPU usage and or processes. I noticed that during the time it takes to show GUI, the RawTherapee process does not show up in the Task Manager and the CPU usage does not cahnge. Does that mean that, as far as Windows is concerned, this task has not even started for the first 50 seconds or so ?
Correction: I was wrong, it does show up on the Task Manager immediately after starting it.
Same here.
It does immediately show up @ taskmanager, but it (=RT) doesn’t do much for a long time…
Like this comment:
I’ve noticed the same. When I run ProcessMonitor (Sysinternals) there is a huge number of entries of RT opening/scanning files, opening handles… but in the mean time, very little happens…
I’ll test RT on our Win10 PC tomorrow.
@PanoMeister Do you have another Gtk3 powered software to test in similar conditions ?
@Hombre Unsure of which GTK @partha’s GIMP 2.9.6 64-bit Standard Edition uses but it loads very slowly on my win7.
@Hombre Never mind then about GIMP and GTK.
Like for @heckflosse, RT 5.3 starts smoothly on my win7 system. I used win10 before: having lots of handles is not unique to RT.
I’ve checked List of GTK applications - Wikipedia this list, but I don’t see any specific indications of GTK3 powered s/w. And I don’t see anything familiar software what I use personally. So; no.
One of the (main) reasons I was looking into RT is the fact that it doesn’t use a database model for storing images and its development data.
Like I said:
and Darktable DOES use a database kind of model.
But I will give the latest DT release a try.
“To cut a long story short, we are extremely pleased – albeit wary – to announce a very first official pre-alpha development snapshot for 64 bit Windows. We know it’s still buggy, but as a sign of goodwill and request for help in testing it we would like to ask you to give it a try” gives me the idea that it’s not a stable release?
I found this version: darktable-2.3.0+941~g3fe3c2749-win64.exe and installed it.
It starts almost instantly! I can’t time it; <1s.
I run an import of about 1500 RAW (D800E NEF) files to see how it performs.
The my computer gets busy… 100-150MB/s disk I/O (scanning the files?) 5-15% CPU util, and then a few minutes later, the import is ready.
And now I know again, why this kind of software is not my thing… 
The UI, the ‘strange’ way of browsing through the files is not for me, sorry @houz
I’ve compared a lot of RAW converters the last few years and the only reason I wanted to switch from the ViewNX-i (and previously ViewNX-2) software from Nikon is because of its slow RAW → TIFF conversion and the limited number of parameters I can use. But in the last 15 (!) years I got use to plain & simple file browsing in the way the OS (like Windows in my case) does that. I don’t want to be depending on some kind of database ‘contraption’ for several hundred thousands of image files.
I think that @houz simply meant that Darktable is also a GTK+3 app, so you should try and see if that takes a long time to start too.
It seems not to be the case, which (probably) means the problem is specific to RT.
BTW, I went ahead and set up a build environment on my windows VM (running win7). Unfortunately however, I can’t reproduce your issue 
On my Windows 10/Pro/64, which used to be 7, I have Darktable and RT installed. They both take about the same time to open. Seven to eight second to open., but once DT has been opened it does seem to open a little faster, about 3 to 4 seconds. RT always takes about 7 to 8.
My computer is an older I5 with 8gb ram, running W10 pro.
Well, we can continue to speculate on the cause for the stalls forever, but it all boils down to fire up GDB, run the debug version of RT in it, and Ctrl+C during the waiting period. As you’ve plenty of time for that (50s are enough), someone with the problem should be able to do so and report back. Mica (@paperdigits) has given that hint at least once days ago, and he’s right in saying you’re no victim if you have the ability to change things (although “victim” was perhaps just bad wording as most of us aren’t native speakers), so please go ahead and give GDB a try.
Thanks,
Flössie
4 Likes
So I fired up RT5.3 on a Win10 machine just after a fresh install (no previous installed was there) and it started in the 8s for first and subsequent launch with an OS up-time of 10mn only. It is very slow to switch from 1 thumbnail to the other, but I guess it’s due to GUI of the lensfun’s tool. We’ll enhance that soon.
I won’t have access to Win10 for the next 2h (someone else require it), then I’ll be able to do other test with an up-time of ~3h.
For the record, when you start a new RT release AND the cache folder is not the same as the previous install (AppData\Local\RawTherapee) AND the folder contains edited images, RT will start a thumbnail update even before the GUI appear that will fully load the images (which can be very large files for panoramas) and fast-demozaice them, then store the thumbnails in the AppData\Local\RawTherapee\cache\images folder. Once this the process is finished, starting RT in that directory is as fast as the 7-8s we’re observing. That could explain the lag of the Preference window.
1 Like
@Hombre: some additional info, regarding your explication of the lag when creating thumbnails.
RT is also slow(ish) when starting it in an empty directory, which contains NO data whatsoever. The same applies for the ‘preferences’ setting; it’s always lagging (at least 1-2s) before it opens up. (?) What is it waiting/searching for then?
So there is nothing to generate/update regarding thumbnails.
I’m happy to test something with the debug version, but the story how to do that exactly is not clear to me. It seems those instructions are mainly targeted at Linux users. And how/what can I generate debugging data? Is there somewhere more ‘readable’ (aka understandable) instructions for a Windows non-programmer, user?
Small notice about semantics of being a ‘victim’. Although I’m certainly not a native English speaker (I’m Dutch), I thought the term ‘being a victim of’ just signifies ‘also suffering from the same issue in this case’? But never mind…