> > > ok... so when it comes to performance, it's better to use
> > > strutctures than arrays and both of those are better than
> > > lists. But what about queries? Queries that are generated
> > > using QueryNew as opposed to SQL statements.
...
> > Incorrect -
> > Arrays are faster by a factor of about 4.  Structures are
> > really slow.
...
> I can't say I've ever compared them, however, the information
> was something that came from a Performance Tips session by Ben
> Forta at a recent developer conference. Structures, Arrays and
> Lists, in that order.

This thread is analogous to asking "which is faster: cars, aircraft or
boats?" The answer, of course, depends on where you're going. Structures,
arrays, lists, and queries, while similar, are intended to be used in
different situations. As long as you use each where appropriate, you're
making the best choice.

Arrays are faster than Structures, unless you're using the Structure to
contain key-value pairs and pull them out at will - which is what Structures
are for. Arrays are faster than lists, unless you're using a string to build
your list in the first place; if you have to convert the string/list to an
array, you'll end up paying the list speed penalty anyway!

If you want to simply contain a bunch of undifferentiated values, use a
one-dimensional Array. If you want to build a variable which contains other
variables, use a Structure. Lists, of course, occur naturally, and if you
want to treat a string as a list, feel free to do so. If you want to use a
Query instead of a two-dimensional Array, again, feel free - even if it's a
bit slower than a two-dimensional Array, you'll probably make up the
difference by being able to use all the tags that support a QUERY attribute.

In any case, if you're concerned about performance, there are places that
are far better to examine, such as your database queries. Have you run
SHOWPLAN with them (if you're using SQL Server, for instance)? Are you
testing your stored procedure performance? Are you updating DB statistics?
You'll get a much better return on investment looking at your SQL, from a
performance perspective.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444

------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.

Reply via email to