Re: [WebDNA] CORRECTION: 60% failure rate using replace in a loop
This WebDNA talk-list message is from 2010
It keeps the original formatting.
numero = 105628
interpreted = N
texte = > I think this might work faster: > > 1- Search the tickets.db for (example) 45 random sku values > 2. Stores these skus in an indexed table > 3- Search the bids.db for the next 45 records with blank > bidderID values > 4- Use replacefounditems to change these bidderID's > based on lookups of the index values in the table I ran a test using this new coding technique and it is 5 times FASTER than my old code. As far as changes are concerned, I UN-nested the searches (which probably makes the most difference) and then I removed the conditional showifs and random values in both code snippets so the test results would be valid and directly comparable. Here's an example of my new code which follows the description quoted above. If *not* nesting search contexts makes this kind of performance improvement maybe this is the approach we should all use on pages that demand the fastest processing: [search db=test/tickets.db&eqemaildatarq=XXX&raemailsort=1&max=45] [table name=set1&fields=idx,sku] [founditems][index] [sku] [/founditems][/table] [/search] [search db=test/bids.db&eqbidderIDdatarq=[blank]&asidxsort=1&idxtype=num&max=45] [replacefounditems]bidTime=[time]&bidderID=[lookup table=set1&value=[index]&lookinfield=idx&returnfield=sku][/replacefounditems] [/search] Note that I did not see any failure of replacefounditems here, so whatever was causing the problem earlier is not breaking this code. :) Sincerely, Kenneth Grome
Associated Messages, from the most recent to the oldest:
> I think this might work faster: > > 1- Search the tickets.db for (example) 45 random sku values > 2. Stores these skus in an indexed table > 3- Search the bids.db for the next 45 records with blank > bidderID values > 4- Use replacefounditems to change these bidderID's > based on lookups of the index values in the table I ran a test using this new coding technique and it is 5 times FASTER than my old code. As far as changes are concerned, I UN-nested the searches (which probably makes the most difference) and then I removed the conditional showifs and random values in both code snippets so the test results would be valid and directly comparable. Here's an example of my new code which follows the description quoted above. If *not* nesting search contexts makes this kind of performance improvement maybe this is the approach we should all use on pages that demand the fastest processing: [search db=test/tickets.db&eqemaildatarq=XXX&raemailsort=1&max=45] [table name=set1&fields=idx,sku]
[founditems][index] [sku] [/founditems][/table] [/search] [search db=test/bids.db&eqbidderIDdatarq=[blank]&asidxsort=1&idxtype=num&max=45]
[replacefounditems]bidTime=
[time]&bidderID=[lookup table=set1&value=[index]&lookinfield=idx&returnfield=sku][/replacefounditems] [/search] Note that I did not see any failure of replacefounditems here, so whatever was causing the problem earlier is not breaking this code. :) Sincerely, Kenneth Grome
Kenneth Grome
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:
WebCatalog2 Feature Feedback (1996)
Security Issue (1997)
math and european notation (1998)
Re:no template caching (1997)
Server crash (1997)
Nesting format tags (1997)
Cookies and webcat (1997)
WebCatalog as a ListServ (1998)
template includes encrypted template (1999)
[WebDNA] CSS Advice (2008)
[WebDNA] Use of :global: (2013)
[OT] sbox error (2003)
Kaaaaahhhhhhhnnnnnnn! (1997)
too many nested tags ... (1997)
&fieldsdir=ra truely random?? (2000)
page redirect in webDNA (1997)
[Fwd: Rotating Banners ... (was LinkExchange)] (1997)
Targeted Redirect (1999)
[!] not working? (1999)
MD5 Encryption (2003)