Backport:

B-g#27501: 5.0 significantly more sys ("kernel") time than 4.1 \
      due to getrusage() calls

Even if profiling is turned off, the parser makes calls to reset 
the state at the beginning of each query.  That would eventually 
instantiate a PROFILE_ENTRY, which does indeed capture resource 
usage.

Instead, now check that profiling is active before progressing
far into the storage/expiration of old entries in the history.
This has the pleasant side-effect that queries to toggle profiling
are not recorded in the history.


mysql-test/r/profiling.result:
  Now after we turn off profiling, the beginning of the next query 
  refuses to enter the profiling code and it discards the info.
sql/sql_profile.cc:
  Add the same condition twice:  Once to abort storing previous 
  query information and the other to abort initialization for this 
  query that is starting.
  
  We do this symmetrically, before and after expiring old history 
  entries, so that the counts are correct.

1 files changed, 11 insertions, 0 deletions

diff --git a/sql/sql_profile.cc b/sql/sql_profile.cc
index 4ee8d1ba9c8..b17bb6daa0d 100644
--- a/sql/sql_profile.cc
+++ b/sql/sql_profile.cc
@@ -493,6 +493,9 @@ void PROFILING::store()
   while (history.elements > thd->variables.profiling_history_size)
     delete history.pop();
 
+  if (likely(((thd)->options & OPTION_PROFILING) == 0))
+    DBUG_VOID_RETURN;
+
   if (current != NULL)
   {
     if (keeping && 
@@ -519,12 +522,20 @@ void PROFILING::store()
   DBUG_VOID_RETURN;
 }
 
+/**
+  Store and clean up the old information and get ready to hold info about this
+  new query.  This is called very often so it must be very lightweight if
+  profiling is not active.
+*/
 void PROFILING::reset()
 {
   DBUG_ENTER("PROFILING::reset");
 
   store();
 
+  if (likely(((thd)->options & OPTION_PROFILING) == 0))
+    DBUG_VOID_RETURN;
+
   if (current != NULL)
     current->reset();
   keep();