VTune is an incredibly powerful and intuitive profiler analyzer. I recently came to know that it is free for personal use and it is available on Linux/Mac/Windows.
Thanks to this blog post here: https://ib-krajewski.blogspot.com/2019/07/vtune-amplifier-and-profiling-mingw-on.html.
Here are some of the analytical graphs I have been able to capture via this suite of tools (I’m trying to analyze the high memory consumption issues with Qt5 port. I am not sure about the accuracy of this tool though. It just looks pretty impressive to me 
).
That sounds interesting. Is there anything you can conclude from these measurements?
Could you elaborate on this? Is memory consumption much higher in Qt 5 than in 4?
I haven’t had time to analyze them yet (just thought it was some impressive graphs to share).
I am currently using/testing a s7-qt5 branch, which sometimes can draw up to 2GB of memory (and as far as I can tell, it could still go up, so I have to restart). While s7 seems to draw more memory than guile1.8, (texmacs-memory) shows that it wasn’t as high as I would expect. So I think it is more or less due to qt5. However, I don’t have anything conclusive to say on this (compared with qt4).
Are there any news in this direction? Did you understood if the memory consumption is from Qt5 or S7?
Hi Max,
I’m pretty sure it is from S7, as reported by its internal memory statistics. However, I haven’t looked further into it. I suspect it is on the scheme side of things (implementation of S7); it happens when I have done fair amount of editing on a document. So from time to time, I have to restart the editor. I have observed no such excessive memory consumption behavior with Guile1.8 + Qt5.
One possibility is that I made some mistake in the glue code which marshal data between C++ and Scheme and some memory is not released. It would be interesting to investigate more the issue.
Indeed. I have tried to check that and don’t recall finding any – these types of bugs are notoriously hard to find 
Yes. But if you see a large memory consumption it could be that many objects are not reclaimed (for some reason or another) due to some bug in my code and not some problems with S7 memory management. Or you have reasons to think otherwise?
I saw that in some of your previous attempt to patch a crash you commented some GC code in the glue, could it be that you observed the strange behaviour then? Do you happen to have it also now? I’ve tried a bit but haven’t seen anything striking. I will try a bit more using the s7 version for some editing.
True, it could be on memory leak within your code. My main reason to suspect otherwise is that I couldn’t find any obvious bugs in your code. Maybe you will have better luck than mine. The behaviour occurs after my patch on the GC (the bug is minor – not returning an NULL pointer; so far only gcc will produce error with optimization flags turned on; clang compiles fine; I’m guessing gcc is using some weird optimization tricks.) The behaviour occurs after some time for me. I was wondering if I was the only one experiencing this bug. Let me know what you observe. Thanks.
I now used it a bit and indeed I saw some large memory occupation (1GB) wrt. to the normal footprint (0.5GB). But sometimes it is also OK. I should do more experiments. Note that s7 keep track of some internal memory statistics, so we could use this to see what is going on. Also it has profiling. See e.g. memory-usage at https://ccrma.stanford.edu/software/snd/snd/s7.html in case you didn’t knew. One can also change programmatically the parameters for the GC.
Yes, I am aware of the memory probing API provided by s7. Perhaps you can checkout this pull request (https://github.com/texmacs/texmacs/pull/60), in particular this commit, which could serve as a quickstart for looking into the memory patterns of s7 (https://github.com/texmacs/texmacs/pull/60/commits/51cabba48598be3d992364eaa4829819ec48e3d7). Over time, it could accumulate to 2GB and above (I have tried tuning many things; it is either memory leaks or s7’s memory management is not suitable for TeXmacs’s usage), which is bad. gc will become quite slow given s7’s “naive” gc implementation compared to other Scheme implementations.
