.jeff wrote: > 5-20ms a piece for a bunch of queries adds up quickly. > > at my count, the execution times for queries and includes for the sidebar > total about 700-750 milliseconds. that's longer than it needs to be. no shit? i'm seeing 98 msecs for every query except the main one. http://members.evolt.org/djc/temp/frontpage.html > much. for example, why is it taking over 7000 milliseconds to join 3 > relatively small tables and return a query resultset just over 700? that's good question. again, i'm seeing about 3000msecs for that query though.. > absolutely ridiculous. solve that and you've solved 90% of the time wasted > rendering the homepage. here's a question, if we're only showing ten rows > at a time on the homepage, why is the blockfactor so high? also, why isn't we're only showing 10 rows, but we're still getting all articles, no? > first of all, these hacks you keep referring to are no longer necessary with > what i've learned about implementing sites using directory-style query > strings. since the architecture i put in place which required the > alphaboxcontroller.cfm file was never used properly, there's really no need > to keep using that file. sorry, i didn't know that.. > you talk about the complication of the architecture. this actually has very > little to do with using directory-style urls. it's designed so that it's > highly modular and can be worked on by multiple people without stepping on > each others toes. i wasn't refering to its modularity and thats not really an issue. personally, i find that the complication does come from the URL scheme, but like i said at the beginning, thse are just my thoughts/opinions > don't even know what to say to that it's so silly. there are most > definitely more than 2 people on this list that have some degree of comfort > with working with the cf source code. sorry. maybe 2 was an exageration.. 4? seriously, i don't know of anyone other than me, you, josh, and matt and seth to an extent(nothing against anyone.. *sigh*).. > well, for starters, we could use a user-defined function to perform the > tasks of the uta custom tag. we could do the same for the pageresults > custom tag. we could be a crapload more careful about how we read/write > session variables. oh.. > don't go trashing the application server because it's not as fast as you'd > like when there's *lots* of room for improvement in the code. i've trashed CF before dont forget :) .djc.