[mv] Performance cost of [if] conditions?

[Christopher Lindsey <lindsey@ncsa.uiuc.edu>]

******    message to minivend-users from Christopher Lindsey <lindsey@ncsa.uiuc.edu>     ******

Howdy all...

   I was wondering if anyone has any information about the performance
   hits involved in setting scratch variables.

   Let me explain why...

   In trying to figure out how to optimize my browsing page, I discovered
   that certain [if] statements were making more database queries.  i.e.

      [if data products::image::[sql-code] ne ""]
         let's do some perl stuff
      [/if]

   By checking the value of the image field in the table products,
   another SQL query is being made.  Since this was in an [sql list][/sql]
   loop (along with some other checks), I was getting around 24 SQL
   queries per page...

   The problem is that I can't figure out how to access the value of
   the field products::image in an if statement without setting a
   scratch variable first.  The following all fail:

      [if sql-param image ne ""]
      [if [sql-param] image ne ""]
      [if '[sql-param]' image ne ""]

   I can do

      [if data products::image::[sql-code] ne ""]
      [if explicit]
      [condition]
         return 1 if '[sql-param image]' ne "";
         return 0;
      [/condition]

   , although I wonder about the efficiency of the condition called
   by perl in the [if explicit] tag.

   What I finally resorted to was kind of icky, but it worked:

      [set name=image interpolate=1][sql-param image][/set]
      [if scratch image ne ""]

   So...  At least I've cleaned up my SQL queries, but I'm wondering
   which of these methods are most effective.  And how much of a
   performance hit does adding [scratch] variables make?

Thanks,

Chris

----------------------------------------------------------------------
Christopher Lindsey, Senior System Engineer
National Center for Supercomputing Applications (NCSA)
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list