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

@@ -248,6 +248,7 @@ sum(id)
 12
 show profiles;
 Query_ID	Duration	Query
+15	#	select count(*) from t1
 16	#	insert into t1 select * from t1
 17	#	insert into t1 select * from t1
 18	#	insert into t1 select * from t1
@@ -277,7 +278,6 @@ Query_ID	Duration	Query
 42	#	insert into t1 values (1), (2), (3)
 43	#	insert into t1 values (1), (2), (3)
 44	#	select * from t1
-45	#	set session profiling = OFF
 set session profiling = ON;
 select @@profiling;
 @@profiling

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