Contributed by Bjorn Tillenius.

Fix a number of problems with the need for speed code:

One is doing this sort of thing:

    Py_DECREF(self->field);
    self->field = newval;
    Py_INCREF(self->field);

without being very sure that self->field doesn't start with a
value that has a __del__, because that almost certainly can lead
to segfaults.

As self->args is constrained to be an exact tuple we may as well
exploit this fact consistently.  This leads to quite a lot of
simplification (and, hey, probably better performance).

Add some error checking in places lacking it.

Fix some rather strange indentation in the Unicode code.

Delete some trailing whitespace.

More to come, I haven't fixed all the reference leaks yet...

and use it for string copy operations.  this gives a 20% speedup on some
string benchmarks.

bug in both:  `className` was referenced before being checked for NULL.

Avoid obsolescence by directly referring to the section.

allocations.  Use PyMem_MALLOC for larger (1k+) chunks.  1%-2% speedup.

Add a PCBuild8 build directory for building with Visual Studio .NET 2005.  Contains a special project to perform profile guided optimizations on the pythoncore.dll, by instrumenting and running pybench.py

to enable use from stringobject

where appropriate

Windows failures.  Who's keeping a bz2 file open?

lining killed performance on certain Intel boxes, and the "aggressive"
macro itself gives most of the benefits on others.

 - Check the correct variable (str_obj, not str) for NULL
 - sep_len was already verified it wasn't 0

Fix compiler warning (and whitespace) on Mac OS 10.4.  (A lot of this code looked duplicated, I wonder if a utility function could help reduce the duplication here.)

set_exc_info(), reset_exc_info():  By exploiting the
likely (who knows?) invariant that when an exception's
`type` is NULL, its `value` and `traceback` are also NULL,
save some cycles in heavily-executed code.

This is a "a kronar saved is a kronar earned" patch:  the
speedup isn't reliably measurable, but it obviously does
reduce the operation count in the normal (no exception
raised) path through PyEval_EvalFrameEx().

The tim-exc_sanity branch tries to push this harder, but
is still blowing up (at least in part due to pre-existing
subtle bugs that appear to have no other visible
consequences!).

Not a bugfix candidate.