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.

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();