digitalmars.D - Export GC Usage Statistics on Request for Profiling
- tcak (12/12) Jul 15 2016 It is great to see memory usage on Xcode while running an iOS app.
- Jack Stouffer (2/15) Jul 15 2016 Do you know about --profile=gc?
- tcak (8/28) Jul 15 2016 1. Never worked for me in a multithreaded program.
- Andrei Alexandrescu (5/13) Jul 15 2016 Wouldn't that make things too slow to be practical? The other profilers
- tcak (9/29) Jul 15 2016 Hmm, I will check it out. Haven't tested it for a while.
- Andrei Alexandrescu (3/8) Jul 15 2016 I think the consecrated method is to use in-memory storage and serve it
- Jacob Carlborg (5/6) Jul 15 2016 Have you tried to run a D application inside Xcode to get the same
- tcak (2/7) Jul 15 2016 Never used D on Xcode, nor I knew it was possible.
- Jacob Carlborg (7/8) Jul 16 2016 Well, when it comes to using the debugger in Xcode or profiling using
It is great to see memory usage on Xcode while running an iOS app. What I thought is that: 1. GC knows available heap memory locations and their length. 2. GC can detect what parts of heap is in use. 3. A program can create a file to write (stdout, stderr, etc.) So, when desired (e.g. use of a compiler flag), on runtime, GC could write statistical information to a file descriptor every time it runs. So, anyone could write a program to read that information to turn it into a graphical chart for profiling information. Does GC have any support to collect this type of information currently?
Jul 15 2016
On Friday, 15 July 2016 at 16:14:39 UTC, tcak wrote:It is great to see memory usage on Xcode while running an iOS app. What I thought is that: 1. GC knows available heap memory locations and their length. 2. GC can detect what parts of heap is in use. 3. A program can create a file to write (stdout, stderr, etc.) So, when desired (e.g. use of a compiler flag), on runtime, GC could write statistical information to a file descriptor every time it runs. So, anyone could write a program to read that information to turn it into a graphical chart for profiling information. Does GC have any support to collect this type of information currently?Do you know about --profile=gc?
Jul 15 2016
On Friday, 15 July 2016 at 16:21:15 UTC, Jack Stouffer wrote:On Friday, 15 July 2016 at 16:14:39 UTC, tcak wrote:1. Never worked for me in a multithreaded program. 2. I am not able to retrieve that data on runtime by another application to see close to real-time statistics. I know that profiling data is kept in memory, and written to file at the end of program. Instead it could write it to a file descriptor and not care about whether a program is reading it. Let the kernel handle that part.It is great to see memory usage on Xcode while running an iOS app. What I thought is that: 1. GC knows available heap memory locations and their length. 2. GC can detect what parts of heap is in use. 3. A program can create a file to write (stdout, stderr, etc.) So, when desired (e.g. use of a compiler flag), on runtime, GC could write statistical information to a file descriptor every time it runs. So, anyone could write a program to read that information to turn it into a graphical chart for profiling information. Does GC have any support to collect this type of information currently?Do you know about --profile=gc?
Jul 15 2016
On 07/15/2016 12:31 PM, tcak wrote:Could you please give it another look. Walter fixed it relatively recently.Do you know about --profile=gc?1. Never worked for me in a multithreaded program.2. I am not able to retrieve that data on runtime by another application to see close to real-time statistics. I know that profiling data is kept in memory, and written to file at the end of program. Instead it could write it to a file descriptor and not care about whether a program is reading it. Let the kernel handle that part.Wouldn't that make things too slow to be practical? The other profilers I know of also keep counters in memory. Andrei
Jul 15 2016
On Friday, 15 July 2016 at 17:04:35 UTC, Andrei Alexandrescu wrote:On 07/15/2016 12:31 PM, tcak wrote:Hmm, I will check it out. Haven't tested it for a while.Could you please give it another look. Walter fixed it relatively recently.Do you know about --profile=gc?1. Never worked for me in a multithreaded program.If it is about speed, we can still use a public shared memory for that purpose. So, statistical messages can be written in shared memory, and other program reads from that to get those messages. A suitable communication protocol can be implemented in way. At the end, our purpose is to provide powerful toys to ease development.2. I am not able to retrieve that data on runtime by another application to see close to real-time statistics. I know that profiling data is kept in memory, and written to file at the end of program. Instead it could write it to a file descriptor and not care about whether a program is reading it. Let the kernel handle that part.Wouldn't that make things too slow to be practical? The other profilers I know of also keep counters in memory. Andrei
Jul 15 2016
On 07/15/2016 03:42 PM, tcak wrote:If it is about speed, we can still use a public shared memory for that purpose. So, statistical messages can be written in shared memory, and other program reads from that to get those messages. A suitable communication protocol can be implemented in way. At the end, our purpose is to provide powerful toys to ease development.I think the consecrated method is to use in-memory storage and serve it upon request (e.g. by means of an API or interrupt). -- Andrei
Jul 15 2016
On 2016-07-15 18:14, tcak wrote:It is great to see memory usage on Xcode while running an iOS app.Have you tried to run a D application inside Xcode to get the same information? Or is it not available due to the GC? -- /Jacob Carlborg
Jul 15 2016
On Friday, 15 July 2016 at 19:22:41 UTC, Jacob Carlborg wrote:On 2016-07-15 18:14, tcak wrote:Never used D on Xcode, nor I knew it was possible.It is great to see memory usage on Xcode while running an iOS app.Have you tried to run a D application inside Xcode to get the same information? Or is it not available due to the GC?
Jul 15 2016
On 2016-07-15 21:39, tcak wrote:Never used D on Xcode, nor I knew it was possible.Well, when it comes to using the debugger in Xcode or profiling using Instruments both can load any application. Although you won't get any demangling in the debugger but if you and the source files to an Xcode project you get source code location. -- /Jacob Carlborg
Jul 16 2016