Date: Wed, 11 Nov 2020 18:22:31 -0800
On Wednesday, 11 November 2020 14:50:07 PST Kyle Knoepfel via Std-Proposals
wrote:
> The STL supports utilities for tracking time spent in particular algorithms
> (through <chrono>, which does much more than that, of course). For
> example:
>
> auto start = std::chrono::steady_clock::now();
> foo();
> auto stop = std::chrono::steady_clock::now();
> std::cout << "Time spent in foo: " << (stop - start).count() << '\n';
>
> The motivation here would be to do something similar, but for memory use:
>
> user_plugin* plugin = create_plugin();
> auto start_mem = std::memory_use(plugin);
> plugin->execute(...);
> auto stop_mem = std::memory_use(plugin);
> std::cout << "Heap memory increase attributed to plugin: " << (stop_mem -
> start_mem).heap << '\n';
I suggest you come up with a prototype first. This is not going to get much
attention until that happens.
Getting the steady clock time was a no-brainer. All OSes already had support
for getting the time, even if the concept of a steady clock was a bit fuzzy.
It's also a call that on Linux takes a handful of nanoseconds to run
(clock_gettime is highly specialised code).
Getting heap totals is not a common operation, at least outside of debugging.
In release mode applications, there may be no tracking at all. There's also a
no standard POSIX API to get it, so it's not easily implementable on a great
many OSes (I don't know if Win32 has such a thing). There are extensions,
which you'll find if they exist and if they are suitable when you write your
prototype. Where the extensions aren't present or known, the implementation
would be a dummy that returns 0 for everything (or -1).
Other questions to answer:
* does "heap" include memory-mapped files? How about anonymous memory maps?
* does "heap" include memory blocks allocated by the OS but not yet by
malloc()?
* does "heap" include overhead?
* does the function return data for the current thread only or for all
threads? If the latter, it may need a "big application lock" to run, which
is not good for performance and interferes with signal safety and fork()
* are the counts expected to be precise? Or can they be rounded up to a page
size?
The answer to some of these questions may seem obvious at first, but the
reason I am asking them is that they are not obvious to implement.
wrote:
> The STL supports utilities for tracking time spent in particular algorithms
> (through <chrono>, which does much more than that, of course). For
> example:
>
> auto start = std::chrono::steady_clock::now();
> foo();
> auto stop = std::chrono::steady_clock::now();
> std::cout << "Time spent in foo: " << (stop - start).count() << '\n';
>
> The motivation here would be to do something similar, but for memory use:
>
> user_plugin* plugin = create_plugin();
> auto start_mem = std::memory_use(plugin);
> plugin->execute(...);
> auto stop_mem = std::memory_use(plugin);
> std::cout << "Heap memory increase attributed to plugin: " << (stop_mem -
> start_mem).heap << '\n';
I suggest you come up with a prototype first. This is not going to get much
attention until that happens.
Getting the steady clock time was a no-brainer. All OSes already had support
for getting the time, even if the concept of a steady clock was a bit fuzzy.
It's also a call that on Linux takes a handful of nanoseconds to run
(clock_gettime is highly specialised code).
Getting heap totals is not a common operation, at least outside of debugging.
In release mode applications, there may be no tracking at all. There's also a
no standard POSIX API to get it, so it's not easily implementable on a great
many OSes (I don't know if Win32 has such a thing). There are extensions,
which you'll find if they exist and if they are suitable when you write your
prototype. Where the extensions aren't present or known, the implementation
would be a dummy that returns 0 for everything (or -1).
Other questions to answer:
* does "heap" include memory-mapped files? How about anonymous memory maps?
* does "heap" include memory blocks allocated by the OS but not yet by
malloc()?
* does "heap" include overhead?
* does the function return data for the current thread only or for all
threads? If the latter, it may need a "big application lock" to run, which
is not good for performance and interferes with signal safety and fork()
* are the counts expected to be precise? Or can they be rounded up to a page
size?
The answer to some of these questions may seem obvious at first, but the
reason I am asking them is that they are not obvious to implement.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Received on 2020-11-11 20:22:36