Re: Small patch to show only memory usage.

["R. Bernstein" <rocky panix com>]

Probably the reason you didn't find the previous mail/post on
gtk-devel-list is that since I haven't subscribed to the mailing list,
my posts go through a moderator; therefore they are delayed. (I think
all have eventually gotten through though.)

As suggested, I've changed to use unified diffs and a newline before
the "{" brace.  I think it was Hawthorne who said ``A foolish
inconsistency is the hobgoblin of...''

However I do not agree with the attitude that seems to be put forth
here that you can slap the user around with gratuitous
incompatibility. g_mem_profile() has probably been around for several
years now (what 3 or 4?) and people may be using it and I don't find
it a compelling reason for breaking it for these people because you
don't want to use one more name. You exaggerate a bit by writing "x
functions" when "x" is in fact 1 more, and the additional function is a
generalization of the existing one -- it is not exactly the same as
the existing function.

Also, as probably the greatest user of this patch, I can say that I
find the parameter to log a message useful and convenient, and perhaps
suggestive of something helpful.  Originally my code did have those
calls to the log routine beforehand -- it was a bit of a pain.  Calls
to track memory are often added, removed and moved around or
conditionally added. Putting everything in one call is convenient.  If
you don't want a message, put NULL as the message parameter and no
message will appear.

And finally as again probably the biggest user of this stuff, I can
say that I'm not sure every time I want to show allocation pools I
also want to show large allocations. For convenience, one could create
a bitmask for these two e.g. G_MEM_SHOW_ALLOCS = GMEM_SHOW_LARGE_ALLOC
| G_MEM_SHOW_ALLOC_SIZE.  By *forcing* these two to be combined
programmers can no longer easily choose. In all of the patches I
submitted, I give the programmer a choice.

It may be more acceptable to slap around a patch submitter -- although
you'll find that you'll probably get fewer people willing to
help. However when you making things more difficult for the
programmers (by making incompatible changes, by reducing choices, 
and by rejecting useful conveniences), I have to take objection. We
are now talking about more people here.

Finally, all the code is and always have been right there in the
open. I'm not sure what the benefit of making suggestion and then
suggestion on top of that when the code's right there for you or
anyone else to change. It just delays things. The delay doesn't hurt
me, since I already have code that works and has been tested and suits
my purpose, although I have to say I wish the GNOME/GTK/GLIB didn't
have the memory leaks it has to the point where I find myself having
to use. Maybe the delay which may contribute to undiscovered memory
leaks is just more of the "slap the end-user around" mentality.

Again this stuff is in ftp://ftp.gtk.org/incoming/gtk-rocky-010304-0.tar.gz
as the README and FAQ on www.gtk.org suggest is what should be done. 

--- ../glib-orig.h	Thu Mar 23 21:34:01 2000
+++ ../glib.h	Thu Feb  1 01:34:04 2001
@@ -1366,8 +1366,22 @@
 
 #endif /* !USE_DMALLOC */
 
-void	 g_mem_profile (void);
-void	 g_mem_check   (gpointer  mem);
+void	 g_mem_profile   (void);
+
+/* Memory summary flags.
+ */
+typedef enum
+{
+  G_MEM_SHOW_ALLOC_SIZE		= 1 << 0,
+  G_MEM_SHOW_LARGE_ALLOC	= 1 << 1,
+  G_MEM_SHOW_ALLOC	        = 1 << 2,
+  G_MEM_SHOW_FREED	        = 1 << 3,
+  G_MEM_SHOW_USED		= 1 << 4,
+  G_MEM_SHOW_ALL		= 0xff
+} GMemSummaryFlags;
+
+void     g_mem_summarize (const gchar *msg, const GMemSummaryFlags show_what);
+void	 g_mem_check     (gpointer  mem);
 
 /* Generic allocators
  */
--- ../gmem-orig.c	Fri May 19 03:25:05 2000
+++ ../gmem.c	Sun Feb  4 07:38:31 2001
@@ -415,16 +415,26 @@
 
 #endif /* ! USE_DMALLOC */
 
-
 void
 g_mem_profile (void)
 {
+  g_mem_summarize (NULL, G_MEM_SHOW_ALL);
+}
+
+void
+g_mem_summarize (const gchar *msg, const GMemSummaryFlags show_what) 
+{
 #ifdef ENABLE_MEM_PROFILE
   gint i;
   gulong local_allocations[MEM_PROFILE_TABLE_SIZE];
   gulong local_allocated_mem;
   gulong local_freed_mem;  
 
+  if (msg != NULL) 
+    {
+      g_log (g_log_domain_glib, G_LOG_LEVEL_INFO,"%s", msg);
+    }
+
   g_mutex_lock (mem_profile_lock);
   for (i = 0; i < MEM_PROFILE_TABLE_SIZE; i++)
     local_allocations[i] = allocations[i];
@@ -433,17 +443,21 @@
   g_mutex_unlock (mem_profile_lock);
 
   for (i = 0; i < (MEM_PROFILE_TABLE_SIZE - 1); i++)
-    if (local_allocations[i] > 0)
+    if (local_allocations[i] > 0 && (show_what & G_MEM_SHOW_ALLOC_SIZE))
       g_log (g_log_domain_glib, G_LOG_LEVEL_INFO,
 	     "%lu allocations of %d bytes", local_allocations[i], i + 1);
   
-  if (local_allocations[MEM_PROFILE_TABLE_SIZE - 1] > 0)
+  if (local_allocations[MEM_PROFILE_TABLE_SIZE - 1] > 0 
+      && (show_what & G_MEM_SHOW_LARGE_ALLOC))
     g_log (g_log_domain_glib, G_LOG_LEVEL_INFO,
 	   "%lu allocations of greater than %d bytes",
 	   local_allocations[MEM_PROFILE_TABLE_SIZE - 1], MEM_PROFILE_TABLE_SIZE - 1);
-  g_log (g_log_domain_glib, G_LOG_LEVEL_INFO, "%lu bytes allocated", local_allocated_mem);
-  g_log (g_log_domain_glib, G_LOG_LEVEL_INFO, "%lu bytes freed", local_freed_mem);
-  g_log (g_log_domain_glib, G_LOG_LEVEL_INFO, "%lu bytes in use", local_allocated_mem - local_freed_mem);
+  if (show_what & G_MEM_SHOW_ALLOC) 
+    g_log (g_log_domain_glib, G_LOG_LEVEL_INFO, "%lu bytes allocated", local_allocated_mem);
+  if (show_what & G_MEM_SHOW_FREED) 
+    g_log (g_log_domain_glib, G_LOG_LEVEL_INFO, "%lu bytes freed", local_freed_mem);
+  if (show_what & G_MEM_SHOW_USED)
+    g_log (g_log_domain_glib, G_LOG_LEVEL_INFO, "%lu bytes in use", local_allocated_mem - local_freed_mem);
 #endif /* ENABLE_MEM_PROFILE */
 }