James' Website

Introduction

• This website is intended as a resource for ASP and VB developers.
• Bits that aren't written or finished yet are marked up with the Incomplete style.
• It is divided into sections discussing different issues
  1. Graphing
     This section provides source code for an ASP include which, without any server-side COM components or any client-side plug-ins, allows you to render several different graph types, including line, stacked area, and pie charts.
     And now for the bad news. It isn't stable. It isn't documented. I think my pie charting routines are stuffed. Some graph types take a massive page weight and a hell of a long time to render. For now it's only suitable for intranets.
     There is also to be a discussion of issues for client-side graphing code (which, unfortunately, I have not fully developed yet).
  2. Sorting
     This section is to provide a serious discussion of sorting problems and sorting algorithms. I shall be providing examples of most of the major alternatives for sorting algorithms, and discussing some of the issues that most columns on this topic overlook (such as, how to speed up case insensitive sorts, how to deal with Null correctly, how to correct the results of unkeyed sorting algorithms to make them keyed, how to mix and match different sort algorithms for different parts of a problem...).
     In addition, I shall be taking the reader on a tour of a large variety of sorting algorithms, including:
     
     1. Quicksort and its cousin the GraphSort (including discussion of versions of Quicksort geared for sorting when there are many duplicates)
     2. Straight Merge Sorts (which are on average slower than Quicksort most of the time but have a better worse case - Straight Merge is the sort for pessimists)
     3. Natural Merge Sorts (which are far and away the best algorithms for "finishing" off a sort on an array where a very few records are a long way from where they should be).
     4. Straight Insertion Sorts (which are good at finishing off sorting when there are very few records roughly in the spots they already should be. The Quicksort examples I give "hand over" to this algorithm for partititions less than about ten elements in size).
     5. Radix Sorts (which are good at sorting large amounts of data that is uniformly distributed and in very random order)
     6. The Bucket (or "Post Box") Sort (which is good at sorting data when you know that it falls into a number of roughly equal-sized subranges, and you know the subrange boundaries)
     7. A "Unique value" sort (which is good when you know there only a very small number of different values in the column being sorted, but you don't know in advance what they will be)
  3. String Performance
     THE most common cause of performance problems in ASP and VB components (at least from what I see on the fastcode newsgroup) is a poor understanding of (and inefficient use of) string operations. This section will discuss string performance and will (eventually) include source code and compiled classes which can deal with most of the string performance problems. Ironically the classes will be VB classes, demonstrating that it is NOT the language itself that is deficient, just the way most of us use it (the problem is that VB makes it very easy to do string operations the wrong way!).
  4. ASP Programming
     The purpose of this section of the site is to illustrate that most of the things people say ASP can't do, it can. You'll find new (and bizarre) ways to use the Eval function, for example, in the first article.
     In the second article (which I haven't written yet, although all the code is written and working), I'll be presenting an engine for displaying tabulated data, complete with formatting and sorting and previous/next page logic, where you need only supply the query SQL and make a one line call to generate a report. No server side components. No session variables.
     I haven't decided what I'll put in in later articles. Sometime I'd like to cover:
     
     1. Calling COM methods that "you can't" call from ASP... from ASP (for example, ones that take ByRef parameters other than variants, functions that return arrays other than arrays of variants), and so on (this can be achieved with a VB Component that queries the type library information for the COM components and then does any necessary type conversions on the fly).
     2. Generating parameterized ASP template files and setting up other ASPs to use them (via an ASP preprocessor) (but first I have to write the code...).
     3. Converting directories of ASP files into VB COM Components (without buying a tool to do this for you; I'll give you one, complete with the source code).
  5. Javascript Programming
     I haven't written any articles for this section as yet, but I was planning, for the first article, to demonstrate how you can avoid those pernicious "object not defined" errors that seem to pop up on every site. The techniques shown in the textbooks *aren't* good enough (not even those in "Inside DHTML". Body.OnLoad cannot be trusted, for example. I'll show you some (strange) techniques that make it possible to avoid these errors completely, even when you are using <SCRIPT> tags to import javascript routines.
  6. VB Programming
  
  Not even an overview yet! To start with this section will probably be mostly links to VB code in articles in other sections (e.g. Sorting). But I'd like to post articles on how to:
  1. Set up almost any VB project so that it can be compiled to use early or late binding, just by changing a compiler switch(*)
  2. Enumerate the properties and methods of any public class or form(*)
  3. Treat any collection as an ADO data source (this will greatly speed up, for example, any situtation where you need to display a list of files) (this'll leverage the technique from the previous article)(*)
  4. Get timing information with microsecond accuracy (though there is now a class on www.vb2themax.com that already does this, so far as I know I wrote mine first - back in mid-1999)(*)
  5. Automatically generate stub code for your classes so they can implement any published COM interface (that VB will let them implement)(*)
  6. Get stack traces without changing your code (it turns out that, with a small C++ component, you can issue stack dumps wherever you need them, making just one call!). For this one I have the code to dump the procedures in the call stack but I haven't hacked the PDB file format to figure out how to dump the values of the parameters (and local variables!) at each level in the stack. But I've looked enough to know that there is enough information available to do this.
  7. Implement a version of Eval that actually works (allowing you evaluate function calls, variables and references to objects.
     I haven't written a full blow version of this yet.
  8. Set up your VB components and applications so that other components (or apps) can trace what they are doing in real time(*).
  9. Issue asynchronous file searches (all of the existing examples I have seen show on how to run file searches make you wait until all the files have been found - this one doesn't)(*)
  10. Put a layer over ADO to translate its awful error messages into ones that will actually help you figure out what is going wrong (I'm only about 1/3 of the way through writing the code for this one!)
  11. Use ODBC over DAO for better performance, but fake the ADO interfaces over the top of that. I know we're told to do OLEDB over ADO, but it's possible to get ODBC/DAO to run about three times faster (and about ten times faster if there are indexes, as the indexing features advertised in ADO don't work properly - or at all - in most versions of ADO).
      I've written one of these but I no longer have the source code.
  I've put a star (*) next to the articles where the code is ready but I haven't written enough explaining how to call it or how it works.

Background

• There are already numerous websites that provide information (and sometimes source code) for ASP and VB developers. There are also mailing lists on which ASP/VB/SQL performance is discussed.
• However, these sources aren't all they might be. The mailing lists and discussion forums for performance, for example, have these problems:
  1. Often the performance analysis is botched, and writers recommend one technique over another even in situations where the one they recommend is not appropriate.
  2. This is partly because people write in to these forums asking "which is faster, A or B", and this sort of question, taken literally, is dangerous. A better form of question is "when is A faster than B", or, when discussing two alternative ways to do something, "what are the performance characteristics of the various techniques for doing X". After all, the choices that the questioner presents might both be bad.
  3. Sweeping claims are made (and mostly accepted). For example it was - and probably still is - widely believed that "compiled code always runs faster than interpreted code". Not so!
  4. Often the performance of the wrong thing is measured. A recent discussion thread on the fastcode newsgroup, for example, was all about the overhead required for sending information back to ASP from COM components. The author claimed that the overhead rose as an exponential function of the number of bytes being passed back. As it happened, he had it wrong. His statistics showed execution time rising as a quadratic function, for fetching back strings from a VB component, but this was entirely due to the use of inefficient techniques to build the strings in the VB component in the first place
• The sites and forums that provide source code suffer from different problems. Let's take sorting as an illustrative example.
  1. Usually where a sort algorithm is provided it is invalid. Some examples:
     1. in the Visual Basic Programmer's Journal (VBPJ) of [date], several sorting algorithms were presented. But the Quicksort implementation was incorrect. When called on to sort an array by a column, it sorted that column correctly, but the values in the other columns were NOT always sorted with the sort key column. In other words, it sorted the column you wanted, but shuffled the other columns between records.
     2. ...most of the published implementations of Quicksort use recursion incorrectly and may run out of stack with some inputs(!).
  2. Too often the articles pushing one particular sort technique start with a comparison with Bubblesort (which is well known to be a very bad algorithm, even for sorting data that is already almost in order). It makes more sense to compare it with another technique that also performs well.
  3. Whole families of sorting algorithms are left unmentioned. Sorting algorithms based on merging (e.g. the Straight and Natural merge sorts) are almost never mentioned. And the fastest sort algorithms of all (Radix sorts) are also given a lot less coverage than they deserve.
• Doubtlessly I will make all of the same mistakes in the articles on this website. But with any luck I will make them less often than they are made elsewhere. And if you tell me about them I'll correct them.

Other things I'd like to put here some day

Performance Analysis

• It'd be nice if somebody wrote up a series of pages that gave answers to questions such as "how long does it take to compare two strings?", in VB6. In ASP. In a VBS component... Bruce McKinney did a nice job of this, way back when, in his book "Hardcore VB", but wouldn't it be nice if we had tables which we could just look up to get estimates of how long things will take, for the languages (and common components, e.g. ADO) in use today?
• I'd love to see some myths exploded with hard numbers. Such as these:
  1. Compiled code runs faster than interpreted code (false, because, for example, compiled VB code isn't really all that compiled. If it were the VB run-time wouldn't be so big. And you should see what's on the stack when a VB program is running. It's scary.
  2. ADO/OLEDB is the fastest way to talk to a database from ASPWell, it ought to be, I agree! But it isn't! DAO/ODBC canes it. But you can't talk DAO straight from ASP, you have to go through components.