Concerning LTO: This is not RT’s but binutils’ fault. CMake uses stock /usr/bin/{ar,ranlib} and those don’t use the LTO plugin, so the relevant sections get lost. To compile with LTO, employ these CMake arguments:
-DWITH_LTO=ON -DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_RANLIB=/usr/bin/gcc-ranlib
@Morgan_Hardwood We could add this to the CMake logic or should at least document it. Adding it to CMakeLists.txt would make LTO GCC specific (but is that a problem?).
HTH,
Flössie
@floessie does that apply to MSYS2 only?
I just compiled dev with -DWITH_LTO="ON" in Sabayon and it worked (for the first time ever)!
sys-devel/binutils-2.29.1-r1
sys-devel/gcc-6.4.0-r1
dev-util/cmake-3.10.2
What will LTO make faster in RT?
I read that newer binutils pick up the LTO plugin correctly, so that might already be the case with your setup. I’m not referring to MSYS2 (I’m Linux only).
Hm, we had a LTO vs. non-LTO shootout in a GitHub issue years ago, and LTO was some percent faster. This is mostly due to better inlining and de-virtualization at link time, I guess. This does not compete with Ingo’s optimization, but adds some speed-up on top.
@floessie something like this?
diff --git a/CMakeLists.txt b/CMakeLists.txt
index cb45c573..f73cf77b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -334,6 +334,16 @@ if(WITH_MYFILE_MMAP)
endif()
if(WITH_LTO)
+ # Using LTO with older versions of binutils requires setting extra flags
+ SET(BINUTILS_VERSION_MININUM "2.29")
+ execute_process(COMMAND ar --version OUTPUT_VARIABLE BINUTILS_VERSION_DETECTED)
+ string(REGEX REPLACE ".* ([0-9.]+)\n.*" "\\1" BINUTILS_VERSION_DETECTED "${BINUTILS_VERSION_DETECTED}")
+ if("${BINUTILS_VERSION_DETECTED}" VERSION_LESS "${BINUTILS_VERSION_MININUM}")
+ SET(CMAKE_AR "/usr/bin/gcc-ar")
+ SET(CMAKE_RANLIB "/usr/bin/gcc-ranlib")
+ message(STATUS "Binutils version detected as less than " ${BINUTILS_VERSION_MININUM} " - setting CMake parameters to enable LTO linking:\n CMAKE_AR=\"" ${CMAKE_AR} "\"\n CMAKE_RANLIB=\"" ${CMAKE_RANLIB} "\"")
+ endif()
+
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -flto")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto")
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -flto")
Looks good. 
I’ve had two (now three) crash issues thus far. My system:
i7 3630
Nvidia 635m
16gb ram
Samsung EVO 850 256gb main drive
128gb Msata as a second drive (my images are here for testing)
Windows 10, most recent patch
Installed 5.4 RC2 along side 5.3.
5.4 definitely opens faster than 5.3!
Navigating to a folder of images that were edited in 5.3, 5.4 crashed.
Reopened, navigated to same folder, crashed again.
Investigating, I found that removing all pp3 files from suspect folder alleviated the crashing. So I added all of them back. This caused the same crash.
So I decided to remove one pp3 at a time to see if one of them was at fault. To my delight, first file removed and 5.4 no longer crashes while navigating to this folder. So I put that pp3 back to verify the issue. Now all seems fine. Removing the file, adding it back, it doesn’t crash any more. I was going to go through the bug logging process, but i can no longer replicate it
By the way, I have other folders with pp3s and no issues.
Second problem, I was editing a photo and experienced a crash:
Applied RCD demosaicing
Exposure panel
Shadows/highlights
tone mapping
HDR tone mapping
Went to details and applied
Impulse
And Luminance. While adjusting this setting, including Detail Recovery, RT crashed. I’ll try to recreate this issue and provide a bug report.
As I was writing this, I opened RT again and tried double clicking an image but was greeted with a window saying that there was an issue accessing something and there was a runtime error. I tried to grab a screen shot, but when I did, my computer screen went black (I’m sure this is a related issue as I have never seen this with my system before) I had to force reboot the system to recover.
Besides running in rawtherapee-debug.exe and recreating an issue to grab a log, is there no other log of any kind created after random crashes?
Thanks. I’ll do what I can to continue to report these issues.
So I worked the RC really hard last night with dozens of images in that troubled folder. And damned if I can replicate any of the problems I mentioned before.
Not sure how to provide any more helpful info. How much longer is the RC open? I’ll continue to try to replicate the aforementioned problems and look for new ones.
The only thing I’ve noticed so far is that it runs really slow on both my Intel i5-2300 2.8GHz with 16GB of RAM machine & my AMD FX-8130 3.4GHz with 32GB of RAM machine. Both of them have SSDs as the main drive & 7200 RPM drives as the secondary drives. Both are running Windows 64bit Professional & have no bloatware. Version 5.3 also ran really slow on both of them.
It takes a few seconds to react to anything. Doing something as simple as saving a PP3 files takes forever. When I click the save button for a PP3 file, it takes a few seconds for the window to open up, takes a few seconds to navigate to the directory, & then it takes a few seconds to save the PP3 file after I hit the save button. Any other adjustments takes forever to load. It’s like it pauses a few seconds every single time I do anything. None of that happens in version 5.2. It’s all instant. I’m still using 5.2.
@The_Squirrel_Mafia
Which 64bit Windows are you using?
I’m on Windows7/64 Professional and can’t confirm your issues.
That’s smells a bit like the Floppy drive A: bug
After building both geeqie and rawtherapee from test sources, on linux amd64 Mint Sylvia,
,…the following was useful in .bashrc
alias geeqie="/home/sandy/programs/geeqie/bin/geeqie"
alias rawtherapee="/home/sandy/programs/rawtherapee/rawtherapee"
To get the new qeeqie to spawn the new rawtherapee from geeqie’s plugins menu I had to edit
/usr/share/appications/rawtherapee.desktop so the Exec line read:
Exec=/home/sandy/programs/rawtherapee/rawtherapee %f
Seems to work fine.
It’s Windows 10. I disabled the floppy in the BIOS for the Intel i5 machine, but it still lags a bit.
Funny thing is that 5.2 works extremely well. Version 5.3 was too slow & I was hoping for 5.4 to have fixed that, but it still lags.
Does that mean, it’s still same speed as before disabling the floppy in BIOS or is it a bit faster now (if so, how much faster)?