partially reversed/fixed-up b7ff56db631: avoid g_slice allocators and performance issues with memory measurements

 * Fixed build problems on Windows
 * g_slice on Windows has been shown to be of little use either
   and it does not work well with the GetProcessMemoryInfo()
   measurements.
   Also, it brings the same problem as on Glibc: Not even command-line
   termination returns the memory to the OS.
   Therefore, we don't use g_slice at all and commented on it.
 * The custom Linux and Windows memory measurement approaches
   have been shown to be inefficient.
   As a workaround, scripts disable memory limiting.
 * A better approach -- but it will only work on Glibc -- might
   be to hook into malloc(), realloc() and free() globally
   and use the malloc_usable_size() of a heap object for
   memory measurements. This will be relatively precise and cheap.
 * We still need the "Object" base class in order to measure
   memory usage as a fallback approach.

1 files changed, 15 insertions, 0 deletions

diff --git a/TODO b/TODO
index e32bf31..d9418a6 100644
--- a/TODO
+++ b/TODO
@@ -234,6 +234,21 @@ Features:
    Macros may retrieve the code and string of the last error.
 
 Optimizations:
+ * The Linux-specific memory limiting using mallinfo() is
+   very slow (50% to 150% slower than the fallback implementation
+   measured in batch mode).
+   The fallback implementation does not come with much of a
+   runtime penalty.
+   Still I've found no faster way of measuring the process heap.
+   A soft resource limit would be ideal but unfortunately,
+   it lets malloc() return NULL and we're not in control of all
+   the mallocs, so glib could abort before we have a chance to
+   react on it.
+   Since the slow-down affects interactive mode as well, disabling
+   limiting in batch mode is merely a workaround.
+   Perhaps Linux should simply use the fallback limiting as well
+   (or support this via a configure option).
+   On Windows (2000), the overhead is approx. the same.
  * Add G_UNLIKELY to all error throws.
  * Instead of using RTTI to implement the immediate editing command
    behaviours in Cmdline::process_edit_cmd() depending on the current