Hi everyone,
I have issues on latest build of ART on M1 Mac which haas 8GB RAM.
The RAM usage is huge and crashing is constant normal thing.
Hi,
Unfortunately I have no access to a Mac, so I won’t be able to help… Sorry 
One thing you can try is turn off mi-malloc (the memory allocation library used by art) and see if that helps. You would need to modify CMakeLists.txt directly though for this.
Thank you for your quick answer and I understand.
@HIRAM Hello, I saw that you build Mac builds of ART, Can you help ?
Ha, that’s nothing…I can get it to chew up 10GB or more real easy!
Here’s my version
This version seems to have cured the crashes with rotated images, but I still experience crashes every now and again.
RawTherapee typically runs at between 400 and 600MB on the same image files and similar processes where applicable.
Just for fun I tried this experiment on Linux (Fedora 40). Loaded an image from Sony A7IV into ART, DT and RT. Enabled my standard basic modules (tone, color, sharpen, local contrast, lens correction) to have somewhat similar results. Memory usage:
ART: 1.9 GB
DT: 1.1 GB
RT: 2.4 GB
Let me try to disable mi-malloc for Mac builds and let’s see what happens
@Matthew1 @Andy_Astbury1 @agriggio Working on a new build without mimalloc.
1 Like
In my shared folder above 
you can find my replacement build with no mimalloc.
Below 
are the results of my measurements, showing much better RAM freeing performance on Mac without mimalloc.
Launched, showing file browser:
Sampling process 62425 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Analysis of sampling ART (pid 62425) every 1 millisecond
Process: ART [62425]
Path: /Applications/ART.app/Contents/MacOS/ART
Load Address: 0x1007e0000
Identifier: us.pixls.art.ART
Version: ??? (???)
Code Type: ARM64
Platform: macOS
Parent Process: ??? [1]
Date/Time: 2024-11-06 23:40:09.265 -0800
Launch Time: 2024-11-06 23:39:51.027 -0800
OS Version: macOS 12.7.6 (21H1320)
Report Version: 7
Analysis Tool: /usr/bin/sample
Physical footprint: 109.1M
Physical footprint (peak): 139.3M
With mimalloc:
Physical footprint: 213.5M
Physical footprint (peak): 215.3M
- - - - - - - - - - - - - - - - - - - - -
Editor with 36 MP NEF opened:
Physical footprint: 875.1M
Physical footprint (peak): 883.5M
With mimalloc:
Physical footprint: 1.3G
Physical footprint (peak): 1.3G
- - - - - - - - - - - - - - - - - - - - -
During saving as jpg:
Physical footprint: 1.6G
Physical footprint (peak): 2.1G
With mimalloc:
Physical footprint: 2.8G
Physical footprint (peak): 2.8G
- - - - - - - - - - - - - - - - - - - - -
Idling after the save:
Physical footprint: 896.8M
Physical footprint (peak): 2.1G
With mimalloc:
Physical footprint: 2.7G
Physical footprint (peak): 2.9G
\huge ======================
How I disabled mimalloc
(I only added the if(NOT APPLE) wrapping the mimalloc block):
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 202cb212c..901674eaa 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -607,22 +607,23 @@ if(_lcms2_fast_float)
set(ART_LCMS_VERSION_INFO "${ART_LCMS_VERSION_INFO}-fastfloat")
endif()
-
-set(HAS_MIMALLOC)
-set(ART_MIMALLOC_VERSION_INFO "N/A")
-if(NOT WITH_SAN)
- find_package(mimalloc)
- if(mimalloc_FOUND)
- if ("${mimalloc_VERSION}" VERSION_LESS 1.4)
- message(FATAL_ERROR "found mimalloc ${mimalloc_VERSION}, but at least 1.4 is required")
+if(NOT APPLE)
+ set(HAS_MIMALLOC)
+ set(ART_MIMALLOC_VERSION_INFO "N/A")
+ if(NOT WITH_SAN)
+ find_package(mimalloc)
+ if(mimalloc_FOUND)
+ if ("${mimalloc_VERSION}" VERSION_LESS 1.4)
+ message(FATAL_ERROR "found mimalloc ${mimalloc_VERSION}, but at least 1.4 is required")
+ else()
+ message(STATUS "using mimalloc library ${mimalloc_VERSION}")
+ set(HAS_MIMALLOC 1)
+ add_definitions(-DWITH_MIMALLOC)
+ set(ART_MIMALLOC_VERSION_INFO "V${mimalloc_VERSION}")
+ endif()
else()
- message(STATUS "using mimalloc library ${mimalloc_VERSION}")
- set(HAS_MIMALLOC 1)
- add_definitions(-DWITH_MIMALLOC)
- set(ART_MIMALLOC_VERSION_INFO "V${mimalloc_VERSION}")
+ message(FATAL_ERROR "ART requires the mimalloc library. Please install it (see https://microsoft.github.io/mimalloc/)")
endif()
- else()
- message(FATAL_ERROR "ART requires the mimalloc library. Please install it (see https://microsoft.github.io/mimalloc/)")
endif()
endif()
1 Like
Awesome, thanks! I was thinking about this simpler patch which should still do the job:
diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -610,7 +610,7 @@
set(HAS_MIMALLOC)
set(ART_MIMALLOC_VERSION_INFO "N/A")
-if(NOT WITH_SAN)
+if(NOT WITH_SAN AND NOT APPLE)
find_package(mimalloc)
if(mimalloc_FOUND)
if ("${mimalloc_VERSION}" VERSION_LESS 1.4)
In my patch I don’t generate any mimalloc-related variables as in set(ART_MIMALLOC_VERSION_INFO "N/A"), but the unsetting set(HAS_MIMALLOC) seems ok. At the time also I wasn’t sure about the WITH_SAN status for Mac, at this time I think the flag is OFF for my particular current system state.
Hello Andy,
Great YT channel with great content about FOSS Photography post-processing.
I’m learning a lot from it about RT , ART or Darktable.
Yeah only ART has this issue and it looks like it’s Mac only.
I tried running ART ( Windows version) through Whisky and no issue there. I mean it’s using a lot of RAM but it doesn’t crash at least but it’s slower.
1 Like
Ok, i trust you more on this (also because you can actually test it :-), I’ll include your patch
Thanks now RAM usage is much better in some situations may be better than RT but I still experience crashes when lunching ART ( file manager ) or opening raw file.
Here are is one of the crash logs.
https://katb.in/xirudiviwoq
Seems like a crash in the CTL interpreter. Were you using any CTL script? If so, which one?
Thanks!
Downloaded this one and it opens then crashes every time I attempt to launch it.
ART Crash.txt (246.6 KB)
Cheers Matthew.
I just wish so much that ART would be stable enough to last for a whole YouTube vid on my Mac Studio! It’s such a brilliant app in my estimation, but on my Mac it’s seriously hard work.
1 Like
Thanks for your answer. I used lumeq.ctl , splittone.ctl , HSL factors , Perceptual, Split toning.
This also seems to indicate a crash in the CTL library. More than that I cannot say unfortunately…
It reminds me of a problem I reported some time ago to @agriggio, with some more or less random crashes when I use CTL’s, and followed by instant crash on ART opening as long as the offending .arp profile is present in the working directory where ART opens.
I could avoid the crash on loading by either removing the .arp profile (not cool because I lose my work) or by clearing the cache.
I tried updating to the latest CTL library but it didn’t help.
This seems to run much better on my macbook air m2. ART feels much faster and (without using CTL scripts) I also did not experienced as many crashes as I did with the previous version (which used to crash regularly while changing folders and building thumbnails.
1 Like