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:
Cannot get subtotal to work (1997)
WebDNA 6 with iTools 8.2 (2006)
Authenticating users without dialog box (1997)
Tab Charactor (1997)
nested showif? (1998)
Math (1997)
Wanted: Broader string manipulation functions (1997)
Spawn doesn't work as advertised ... (2000)
WebCatalog Upgrade Pricing? (1997)
& in Lookups (1997)
[WebDNA] Error 500 with SUMM=T (2017)
Emailer port change (1997)
Some shell fun (2004)
information on Vieworders.tpl (1998)
WebCat b15 Mac plug-in (1997)
Problems with [Applescript] (1997)
WebCat2b13MacPlugin - [math][date][/math] problem (1997)
how realize an advertiser ? (2005)
Requiring that certain fields be completed (1997)
emailer w/F2 (1997)