Entropy Stew wrote:

I was reading a game once, and it had the most beautiful means to do a task switch between the two players. It used an array to hold all the information for each of the players, one was number 1, and the other player was 2. The particular player whose turn it was, was stored in the variable P. So the entire switch between which player is up consists of the following:

P = 3 - P

If P, the current player number is 1, it's now 2. If it was 2, it's now 1. Extremely simple and very elegant solution.

This is exactly the sort of cute algorithm one should avoid when trying to keep things obvious and maintainable. I don't know how you could go on about keeping things simple then use this branch-avoiding microoptimization as an example. Even cuter (though functionally equivalent) would be P = P xor 3.

Entropy Stew wrote:

A tree structure is a good idea when working with slow machines and helps overcome the speed problems we had on (what are now older and less capable) systems in the past. It's way too complicated now in view of the raw speed of most current machines.

No, a tree is a good idea when you have data ideally represented by one. It is not remotely complicated - it's a basic fucking data structure. Fast processors have not obviated the need for algorithms faster than linear time, either.

Entropy Stew wrote:

When you're programming a text-heavy 16-bit application on a PDP-11 minicomputer from the 1970s & 1980s or on an 8086 which lacks string processing instructions, string searches and comparisons are expensive in terms of processor time and tree structures are a good compromise. When writing a program for a IA32 or 64-bit processor that includes good string search routines as part of the instruction set, string comparisons are much cheaper and a tree structure is no longer as necessary unless you have huge data structures.

I'm writing a program that will collect identifiers in order to show where they are used in the source program it scans. For a typical program today, say a 20,000 line app that has perhaps 8-10 files, uses maybe 500 identifiers - an identifier being a variable, a function, a procedure, a record, etc. - and has perhaps 15,000 uses of these 500 identifiers might take two seconds to generate.

If I was targeting old machines or program systems of more than a million lines I might be more concerned. Besides, I do have at least one "stealth" feature I am using to improve performance, which I got the idea from a really good cross-reference program (but not good enough for today's Object Pascal programming language) someone else wrote back around 1980. The list of identifiers in my program is not one huge list, but an array of linked lists of the first character of the identifier. This breaks the identifier list into roughly 27 lists, each for the 26 letters and the underscore, the valid characters that an identifier can start with. If speed did become a problem, I could create an array of 27*38 lists, and capture the first two characters of an identifier (first char: a-z and _; second char: a-z, _, 0-9, and nul (nul is for 1 character identifiers, like I, C, or K).

Why in the name of Knuth are you kludging arrays of linked lists into a 27 bucket hash collision when you could be doing it properly? "n is tiny so I don't give a shit" is a completely acceptable answer right up until you start writing some halfassed algo to speed up your bodge; that shit is indefensible.