Optimizing [founditems]
This WebDNA talk-list message is from 2000
It keeps the original formatting.
numero = 27116
interpreted = N
texte = Just curious: I state, a search can be considered as active until [/search]. So we should keep the code within the search context as short as possible.Most responsibe for speed is: 1 - The amount of code in the whole template (loading time). 2 - The type of search (complex or not). 3 - The amount and complexity of code within [founditems]. 4 - Available RAM, number and size of loaded databases. Example 1 Single [founditems] and many, many stuff depending on a two-state variable: --------------------------------------- [search...] [founditems] [showif [MyVariable]=on] ...many difficult things to do... [/showif] [showif [MyVariable]=off] ...many difficult things to do... [/showif] [/founditems] [/search] --------------------------------------- I do this most times and (shame) I believe it is the worst method. we have to load one huge page first, then validate all showif's within [founditems]. And showif's can get much more complex than in the example! Example 2 Two [founditems] and many, many stuff depending on a two-state variable: --------------------------------------- [search...] [showif [MyVariable]=on] [founditems] ...many difficult things to do... [/founditems] [/showif] [showif [MyVariable]=off] [founditems] ...many difficult things to do... [/founditems] [/showif] [/search] --------------------------------------- Overall code is equal, but less to do within [founditems]. Might fit better for medium size. I think about adopting this method for all rather short standard searches. Nonsense? Just theory? Example 3 One [founditems] and different include's depending on a multi-state variable: --------------------------------------- [search...] [founditems] [include result_[MyVariable].inc] [/founditems] [/search] --------------------------------------- 5 Lines only and loading just what needed. It requires more templates, but is still maintainable. Now my question: Does example 3 give us most possible speed, or might we loose performance while loading files from disk? Peter ------------------------------------------------------------- Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. To end your Mail problems go to
.This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
Associated Messages, from the most recent to the oldest:
| |
- Optimizing [founditems] (Peter Ostry 2000)
|
Just curious: I state, a search can be considered as active until [/search]. So we should keep the code within the search context as short as possible.Most responsibe for speed is: 1 - The amount of code in the whole template (loading time). 2 - The type of search (complex or not). 3 - The amount and complexity of code within [founditems]. 4 - Available RAM, number and size of loaded databases. Example 1 Single [founditems] and many, many stuff depending on a two-state variable: --------------------------------------- [search...] [founditems] [showif [MyVariable]=on] ...many difficult things to do... [/showif] [showif [MyVariable]=off] ...many difficult things to do... [/showif] [/founditems] [/search] --------------------------------------- I do this most times and (shame) I believe it is the worst method. we have to load one huge page first, then validate all showif's within [founditems]. And showif's can get much more complex than in the example! Example 2 Two [founditems] and many, many stuff depending on a two-state variable: --------------------------------------- [search...] [showif [MyVariable]=on] [founditems] ...many difficult things to do... [/founditems] [/showif] [showif [MyVariable]=off] [founditems] ...many difficult things to do... [/founditems] [/showif] [/search] --------------------------------------- Overall code is equal, but less to do within [founditems]. Might fit better for medium size. I think about adopting this method for all rather short standard searches. Nonsense? Just theory? Example 3 One [founditems] and different include's depending on a multi-state variable: --------------------------------------- [search...] [founditems] [include result_[MyVariable].inc] [/founditems] [/search] --------------------------------------- 5 Lines only and loading just what needed. It requires more templates, but is still maintainable. Now my question: Does example 3 give us most possible speed, or might we loose performance while loading files from disk? Peter ------------------------------------------------------------- Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server. To end your Mail problems go to .This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to
Peter Ostry
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
SetHeader not Working (2006)
Time/date formatting %X doesn't work ... (1997)
Can't load tmpl files (1997)
Change to 5.0 per website licensing (2003)
WebCatalog Beta Documentation (1997)
eMailer replacement? (1998)
Multiple Pulldowns (1997)
Template not found error messages (1997)
RAM variables (1997)
Robert Minor duplicate mail (1997)
Which GUI HTML editors work with WC ? (1997)
how to do [search] params on the fly? (2004)
Word wrapping (1997)
OT: test (1998)
Frames and WebCat (1997)
searches with dash, period etc. (2000)
Re2: AAgghh!! Help, please. SSL strikes again. (1997)
[append] problem (1997)
Help! WebCat2 bug (1997)
return missing item (was:WebCat Sales) (1997)