On Mar 16, 2014, at 05:14, René J.V. Bertin wrote: > I use clang to avoid C++ lib clashes on recent OS X versions, MacPort's own > 3.3 (because 3.0 has known issues), and it is apparently not quite efficient > in its memory usage. There's 1 file in particular, gmic.cpp, that sees VM > usage grow to about 20GB at one point, which is never released and may > explain why I've always had to kill clang after upwards of 30 minutes of > processing (when it in fact appeared to be almost idle). > GCC (MacPorts 4.7) has no such issues, takes less than 2.5GB of memory and > terminates in 3-4 minutes to produce a 16MB object file. My Calligra binaries > thus run with a gmic module compiled with g++ ... > > This is not just an OS X issue; I've tried compiling the file with the same > options under Linux, and a similar thing happens. Except that on my Linux box > with its hard-wired 10GB of swap, VM usage remains limited to about 7GB. > > What do we know about the way clang handles its internal memory allocations > and about possible options to limit that?
I too have seen clang take an extraordinary amount of memory when compiling certain ports, to the extent that I had to disable parallel building to limit the number of clang processes, and clear off many gigs of disk space to make room for swap. I do not know of any options to change that behavior. I do not know how to file a meaningful bug report about this with the developers of clang. This was an older version of clang, on older hardware with limited memory; I haven’t noticed any such problems on my new machine which has gobs of memory and the current versions of things. On Mar 16, 2014, at 06:03, René J.V. Bertin wrote: > Heck, it even looks as if clang uses a single process that handles all the > subsequent steps for which traditional compilers use different applications > (and it's my experience that -pipe is rarely a good idea for big projects > with parallel building). Thus, if it's the preprocessor that needs those 20GB > of memory, the footprint continues to hurt performance of all subsequent > steps, which would explain why I see a clang process that's sitting at 5-15% > CPU usage for such a long time. Very annoying if the rest of the machine > grinds to an almost halt when it's basically doing nothing! Whether or not MacPorts uses the -pipe flag is controlled by the configurepipe setting in macports.conf. If changing it to no makes the build work better, please let us know. We changed the default of that setting from no to yes several years ago, presumably because we thought it would perform better, but I think that was before we were using clang. On Mar 16, 2014, at 09:34, Christopher Jones wrote: > What OSX version are you running ? 3.4 and 3.5 install just fine for me on > OSX 10.9… No idea if clang 3.4 or 3.5 are supposed to work on older OSX > releases (I know the converse has problems, clang versions older than 3.3 do > not install on OSX 10.9). clang 3.5 and later require C++11, and will say so if you try to install them on a system without C++11. Effectively, this means clang 3.5 and later require OS X 10.9 Mavericks or later. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
