Re: [mv] Performance cost of [if] conditions?

[Mike Heins <mike@minivend.com>]

******    message to minivend-users from Mike Heins <mike@minivend.com>     ******

Quoting 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?

You have a data problem more than anything. Why are you so caught
up in the ' ne "" ' thing? Is your image going to equal the string '0' ?

I have said the below many times, though apparently not in the
right places or in the right ways. Lets try this way:

	WORST:   [if data products::image::[sql-code] ne ""]
	BAD:     [set image][sql-data products image][/set][if scratch image ne ""]
	BETTER:  [set image][sql-data products image][/set][if scratch image]
	BEST:    [if-sql-data products image]

They are in essence the same thing, unless you account for the
value of 0 which will return true in the first two cases and false 
in the latter.

The first causes an extra database access and a Perl conditional evaluation.
The seconds causes a Perl conditional evaluation.
The third causes Minivend tag parsing.
The last causes none of the above, as [if-sql-data ...] is really part
of the [sql ... ] tag parse, and is an order of magnitude or more faster
than any of the others. Probably several orders of magnitude faster than
the first, or more. MV4 has [if-sql-param ...] too (later versions of 
3 may, but I forget).

The last cannot be nested, alas, but there are almost always ways to
get around that. Put the expensive things on the inside, of course. 8-)

-- 
Mike Heins                          http://www.minivend.com/  ___ 
                                    Internet Robotics        |_ _|____
My wife is great.  She doesn't      131 Willow Lane, Floor 2  | ||  _ \
care where I go, just as long as I  Oxford, OH  45056         | || |_) |
don't have any fun.                 <mikeh@minivend.com>     |___|  _ <
 -- Lee Trevino                     513.523.7621 FAX 7501        |_| \_\
-
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