Here are the requirements:
Must be alphanumeric, 8-10 characters so that it is user friendly. These will be stored as unique keys in database. I am using Guids as primary keys so an option to use GUids to generate these unique Ids would be preferable.
I am thinking on the lines of a base-n converter that takes a Guid and converts to an 8 character unique string.
Short, light-weight algorithm preferred as it would be called quite often.
The simplest thing that could possibly work is a counter that is incremented every time a value is required. Eight (left-zero-padded) digits gives you 100 million possible values 00000000 thru 99999999 (although you might interject spaces or hyphens for human readability, as in 000-000-00).
If you will need more than 100 million values, you could either increase the length or use letters in alternate positions. Using A0A0A0A0 thru Z9Z9Z9Z9 gives you over four-and-a-half billion possible values (4,569,760,000) available. It is a trivial bit of code to take a long integer and produce such an encoding (mod 10 for the rightmost digit, div by 10 then mod 26 for the rightmost letter, etc.) If you have the memory to burn, the fastest way is to convert the counter to a mod 260 array, and use each mod 260 value as an index into an array of two-character strings ("A0", "A1", "A2", and so on thru "A9", "B0", "B1", etc. thru "Z9").
The problem with base 36 (mentioned in another reply) is that you not only have to worry about reader confusion of similar characters (one vs. I, zero vs. O, two vs. Z, five vs. S) but also about combinations of adjacent letters that might be perceived by readers as spelling distasteful or obscene words or abbreviations.