|
camusflage
Starting Member
USA
26 Posts |
 Posted - 28 May 2001 : 20:12:42
|
Hrmmm. A couple of tips from experience...
ALWAYS use option explicit. MS says you get about a 10% performance boost, plus the added benefit of being able to debug when you fat finger variables.
Try not to break from asp to html to asp a lot. Context switching is expensive. If you just need a snippet of html from your asp logic, use response.write instead.
Buffer output. Always. This is nicer to the network subsystem, and allows your page to process before doing any redirection. Some browsers don't like receiving information before being told to go somewhere else. Before you start doing something you already know might take a while to process, do a response.flush so that the user isn't sitting there thinking nothing's happening.
When possible, use OLEDB vs ODBC. In recent iterations of MDAC (1.5+, IIRC), ODBC anymore is just a front-end to OLEDB. Cut out the middleman and use OLEDB directly.
If given the choice between building sql calls in asp and using a stored procedure to run it, always go with the SP. Precompiled statements are approx. 20% faster than dynamic statements.
If you use objects, try to always set them to nothing (you said you're doing it). This isn't so much for optimization as it is cleaning up after yourself. Although ASP closes everything at the end of page execution, sometimes it doesn't get all the bits. Those bits add up over time, and become a memory leak in your application. While I suppose this can happen with simple variables, it's more problematic with objects.
If it's a constant, define it as one. Constants have lower memory overhead and faster creation time than do variables. const conName = "constant"
If you're using code to do a particular function, and you have a component available to do the same thing, in most cases, it's better to use the component instead of the code. Compiled code is an order of magnitude faster than scripted code.
Mike
|
 |
|
Topic Locked
