Commit Graph

1613 Commits

Author SHA1 Message Date
Raymond Hettinger bc552ce1b8 SF 582071 clarified the .split() method's docstring to note that sep=None
will trigger splitting on any whitespace.
2002-08-05 06:28:21 +00:00
Tim Peters 66860f6da4 Sped the usual case for sorting by calling PyObject_RichCompareBool
directly when no comparison function is specified.  This saves a layer
of function call on every compare then.  Measured speedups:

 i    2**i  *sort  \sort  /sort  3sort  +sort  %sort  ~sort  =sort  !sort
15   32768  12.5%   0.0%   0.0% 100.0%   0.0%  50.0% 100.0% 100.0% -50.0%
16   65536   8.7%   0.0%   0.0%   0.0%   0.0%   0.0%  12.5%   0.0%   0.0%
17  131072   8.0%  25.0%   0.0%  25.0%   0.0%  14.3%   5.9%   0.0%   0.0%
18  262144   6.3% -10.0%  12.5%  11.1%   0.0%   6.3%   5.6%  12.5%   0.0%
19  524288   5.3%   5.9%   0.0%   5.6%   0.0%   5.9%   5.4%   0.0%   2.9%
20 1048576   5.3%   2.9%   2.9%   5.1%   2.8%   1.3%   5.9%   2.9%   4.2%

The best indicators are those that take significant time (larger i), and
where sort doesn't do very few compares (so *sort and ~sort benefit most
reliably).  The large numbers are due to roundoff noise combined with
platform variability; e.g., the 14.3% speedup for %sort at i=17 reflects
a printed elapsed time of 0.18 seconds falling to 0.17, but a change in
the last digit isn't really meaningful (indeed, if it really took 0.175
seconds, one electron having a lazy nanosecond could shift it to either
value <wink>).  Similarly the 25% at 3sort i=17 was a meaningless change
from 0.05 to 0.04.  However, almost all the "meaningless changes" were
in the same direction, which is good.  The before-and-after times for
*sort are clearest:

before after
  0.18  0.16
  0.25  0.23
  0.54  0.50
  1.18  1.11
  2.57  2.44
  5.58  5.30
2002-08-04 17:47:26 +00:00
Tim Peters 6bdbc9e0b1 SF bug 590366: Small typo in listsort:ParseTuple
The PyArg_ParseTuple() error string still said "msort".  Changed to "sort".
2002-08-03 02:28:24 +00:00
Guido van Rossum f4be427c46 Tim found that once test_longexp has run, test_sort takes very much
longer to run than normal.  A profiler run showed that this was due to
PyFrame_New() taking up an unreasonable amount of time.  A little
thinking showed that this was due to the while loop clearing the space
available for the stack.  The solution is to only clear the local
variables (and cells and free variables), not the space available for
the stack, since anything beyond the stack top is considered to be
garbage anyway.  Also, use memset() instead of a while loop counting
backwards.  This should be a time savings for normal code too!  (By a
probably unmeasurable amount. :-)
2002-08-01 18:50:33 +00:00
Guido van Rossum 0dbab4c560 SF patch 588728 (Nathan Srebro).
The __delete__ method wrapper for descriptors was not supported

(I added a test, too.)

2.2 bugfix candidate.
2002-08-01 14:39:25 +00:00
Tim Peters a64dc245ac Replaced samplesort with a stable, adaptive mergesort. 2002-08-01 02:13:36 +00:00
Tim Peters 92f81f2e63 Checking in the doc file for "timsort". There's way too much here to
stuff into code comments, and lots of it is going to be useful again (but
hard to predict exactly which parts of it ...).
2002-08-01 00:59:42 +00:00
Neal Norwitz cee5ca060b SF patch #587889, fix memory leak of tp_doc 2002-07-30 00:42:06 +00:00
Michael W. Hudson 56796f672f Fix for
[ 587875 ] crash on deleting extended slice

The array code got simpler, always a good thing!
2002-07-29 14:35:04 +00:00
Mark Hammond a290527376 Excise DL_IMPORT/EXPORT from object.h, and related files. This patch
also adds 'extern' to PyAPI_DATA rather than at each declaration, as
discussed with Tim and Guido.
2002-07-29 13:42:14 +00:00
Neal Norwitz 88fe4ff5a9 Fix the problem of not raising a TypeError exception when doing:
'%g' % '1'
    '%d' % '1'

Add a test for these conditions
Fix the test so that if not exception is raise, this is a failure
2002-07-28 16:44:23 +00:00
Martin v. Löwis 673c0a2247 Patch #574867: Correct list.extend docstring. 2002-07-28 16:35:57 +00:00
Neal Norwitz 7beeed5dfd SF patch #577031, remove PyArg_Parse() since it's deprecated 2002-07-28 15:19:47 +00:00
Martin v. Löwis 75d2d94e0f Patch #554716: Use __va_copy where available. 2002-07-28 10:23:27 +00:00
Skip Montanaro 35b37a5c11 tighten up the unicode object's docstring a tad 2002-07-26 16:22:46 +00:00
Jeremy Hylton 73a088e3fa Don't be so hasty. If PyInt_AsLong() raises an error, don't set ValueError. 2002-07-25 16:43:29 +00:00
Jeremy Hylton f20fcf9fed Complain if __len__() returns < 0, just like classic classes.
Fixes SF bug #575773.

Bug fix candidate.
2002-07-25 16:06:15 +00:00
Michael W. Hudson 206d8f818f Silly typo. Not sure how that got in. 2002-07-19 15:52:38 +00:00
Michael W. Hudson f0d777c56b A few days ago, Guido said (in the thread "[Python-Dev] Python
version of PySlice_GetIndicesEx"):

> OK.  Michael, if you want to check in indices(), go ahead.

Then I did what was needed, but didn't check it in.  Here it is.
2002-07-19 15:47:06 +00:00
Tim Peters 330f9e9581 More sort cleanup: Moved the special cases from samplesortslice into
listsort.  If the former calls itself recursively, they're a waste of
time, since it's called on a random permutation of a random subset of
elements.  OTOH, for exactly the same reason, they're an immeasurably
small waste of time (the odds of finding exploitable order in a random
permutation are ~= 0, so the special-case loops looking for order give
up quickly).  The point is more for conceptual clarity.
Also changed some "assert comments" into real asserts; when this code
was first written, Python.h didn't supply assert.h.
2002-07-19 07:05:44 +00:00
Tim Peters 0fe977c4a9 binarysort() cleanup: Documented the key invariants, explained why they
imply this is a stable sort, and added some asserts.
2002-07-19 06:12:32 +00:00
Tim Peters 326b44871e listreverse(): Don't call the new reverse_slice unless the list
has something in it (else ob_item may be a NULL pointer).
2002-07-19 04:04:16 +00:00
Tim Peters a8c974c157 Cleanup yielding a small speed boost: before rich comparisons were
introduced, list.sort() was rewritten to use only the "< or not <?"
distinction.  After rich comparisons were introduced, docompare() was
fiddled to translate a Py_LT Boolean result into the old "-1 for <,
0 for ==, 1 for >" flavor of outcome, and the sorting code was left
alone.  This left things more obscure than they should be, and turns
out it also cost measurable cycles.

So:  The old CMPERROR novelty is gone.  docompare() is renamed to islt(),
and now has the same return conditinos as PyObject_RichCompareBool.  The
SETK macro is renamed to ISLT, and is even weirder than before (don't
complain unless you want to maintain the sort code <wink>).

Overall, this yields a 1-2% speedup in the usual (no explicit function
passed to list.sort()) case when sorting arrays of floats (as sortperf.py
does).  The boost is higher for arrays of ints.
2002-07-19 03:30:57 +00:00
Tim Peters 3b01a1217f Trimmed trailing whitespace. 2002-07-19 02:35:45 +00:00
Tim Peters 8e2e7ca330 Cleanup: Define one internal utility for reversing a list slice, and
use that everywhere.
2002-07-19 02:33:08 +00:00
Jeremy Hylton d1fedb6ab5 Remove extraneous semicolon.
(Silences compiler warning for Compaq C++ 6.5 on Tru64.)
2002-07-18 18:49:52 +00:00
Jeremy Hylton 938ace69a0 staticforward bites the dust.
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure.  Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers.  (In
fact, we expect that the compilers are all fixed eight years later.)

I'm leaving staticforward and statichere defined in object.h as
static.  This is only for backwards compatibility with C extensions
that might still use it.

XXX I haven't updated the documentation.
2002-07-17 16:30:39 +00:00
Guido van Rossum ca5ed5b875 Remove the next() method -- one is supplied automatically by
PyType_Ready() because the tp_iternext slot is set (fortunately,
because using the tp_iternext implementation for the the next()
implementation is buggy).  Also changed the allocation order in
enum_next() so that the underlying iterator is only moved ahead when
we have successfully allocated the result tuple and index.
2002-07-16 21:02:42 +00:00
Guido van Rossum 86d593e110 Remove the next() method -- one is supplied automatically by
PyType_Ready() because the tp_iternext slot is set.  Also removed the
redundant (and expensive!) call to raise StopIteration from
rangeiter_next().
2002-07-16 20:47:50 +00:00
Guido van Rossum 2147df748f Make StopIteration a sink state. This is done by clearing out the
di_dict field when the end of the list is reached.  Also make the
error ("dictionary changed size during iteration") a sticky state.

Also remove the next() method -- one is supplied automatically by
PyType_Ready() because the tp_iternext slot is set.  That's a good
thing, because the implementation given here was buggy (it never
raised StopIteration).
2002-07-16 20:30:22 +00:00
Guido van Rossum 613bed3726 Make StopIteration a sink state. This is done by clearing out the
object references (it_seq for seqiterobject, it_callable and
it_sentinel for calliterobject) when the end of the list is reached.

Also remove the next() methods -- one is supplied automatically by
PyType_Ready() because the tp_iternext slot is set.  That's a good
thing, because the implementation given here was buggy (it never
raised StopIteration).
2002-07-16 20:24:46 +00:00
Guido van Rossum 6b6272c857 Whitespace normalization. 2002-07-16 20:10:23 +00:00
Guido van Rossum 86103ae531 Make StopIteration a sink state. This is done by clearing out the
it_seq field when the end of the list is reached.

Also remove the next() method -- one is supplied automatically by
PyType_Ready() because the tp_iternext slot is set.  That's a good
thing, because the implementation given here was buggy (it never
raised StopIteration).
2002-07-16 20:07:32 +00:00
Jeremy Hylton 719841e2fb The object returned by tp_new() may not have a tp_init.
If the object is an ExtensionClass, for example, the slot is not even
defined.  So we must check that the type has the slot (implied by
HAVE_CLASS) before calling tp_init().
2002-07-16 19:39:38 +00:00
Guido van Rossum 5086e49a6e Make list_iter() really static. 2002-07-16 15:56:52 +00:00
Guido van Rossum 03013a0130 valid_identifier(): use an unsigned char* so that isalpha() will do
the right thing even if char is unsigned.
2002-07-16 14:30:28 +00:00
Tim Peters 58cf361e35 docompare(): Another reasonable optimization from Jonathan Hogg for the
explicit comparison function case:  use PyObject_Call instead of
PyEval_CallObject.  Same thing in context, but gives a 2.4% overall
speedup when sorting a list of ints via list.sort(__builtin__.cmp).
2002-07-15 05:16:13 +00:00
Tim Peters 7a1f91709b WINDOWS_LEAN_AND_MEAN: There is no such symbol, although a very few
MSDN sample programs use it, apparently in error.  The correct name
is WIN32_LEAN_AND_MEAN.  After switching to the correct name, in two
cases more was needed because the code actually relied on things that
disappear when WIN32_LEAN_AND_MEAN is defined.
2002-07-14 22:14:19 +00:00
Guido van Rossum b6d29b7856 Undef MIN and MAX before defining them, to avoid warnings on certain
platforms.
2002-07-13 14:31:51 +00:00
Jeremy Hylton a4b4c3bf05 Don't declare a function with staticforward.
Just declare it static so that lame (BAD_STATIC_FORWARD) compilers
don't see a mismatch between the prototype and the function.
2002-07-13 03:51:17 +00:00
Tim Peters f2a0473350 docompare(): Use PyTuple_New instead of Py_BuildValue to build compare's
arg tuple.  This was suggested on c.l.py but afraid I can't find the msg
again for proper attribution.  For

    list.sort(cmp)

where list is a list of random ints, and cmp is __builtin__.cmp, this
yields an overall 50-60% speedup on my Win2K box.  Of course this is a
best case, because the overhead of calling cmp relative to the cost of
actually comparing two ints is at an extreme.  Nevertheless it's huge
bang for the buck.  An additionak 20-30% can be bought by making the arg
tuple an immortal static (avoiding all but "the first" PyTuple_New), but
that's tricky to make correct since docompare needs to be reentrant.  So
this picks the cherry and leaves the pits for Fred <wink>.

Note that this makes no difference to the

    list.sort()

case; an arg tuple gets built only if the user specifies an explicit
sort function.
2002-07-11 21:46:16 +00:00
Jeremy Hylton df3f793516 Extend function() to support an optional closure argument.
Also, simplify some ref counting for other optional arguments.
2002-07-11 18:30:27 +00:00
Tim Peters 3459251d5a object.h special-build macro minefield: renamed all the new lexical
helper macros to something saner, and used them appropriately in other
files too, to reduce #ifdef blocks.

classobject.c, instance_dealloc():  One of my worst Python Memories is
trying to fix this routine a few years ago when COUNT_ALLOCS was defined
but Py_TRACE_REFS wasn't.  The special-build code here is way too
complicated.  Now it's much simpler.  Difference:  in a Py_TRACE_REFS
build, the instance is no longer in the doubly-linked list of live
objects while its __del__ method is executing, and that may be visible
via sys.getobjects() called from a __del__ method.  Tough -- the object
is presumed dead while its __del__ is executing anyway, and not calling
_Py_NewReference() at the start allows enormous code simplification.

typeobject.c, call_finalizer():  The special-build instance_dealloc()
pain apparently spread to here too via cut-'n-paste, and this is much
simpler now too.  In addition, I didn't understand why this routine
was calling _PyObject_GC_TRACK() after a resurrection, since there's no
plausible way _PyObject_GC_UNTRACK() could have been called on the
object by this point.  I suspect it was left over from pasting the
instance_delloc() code.  Instead asserted that the object is still
tracked.  Caution:  I suspect we don't have a test that actually
exercises the subtype_dealloc() __del__-resurrected-me code.
2002-07-11 06:23:50 +00:00
Tim Peters 889f61dcfb Documented PYMALLOC_DEBUG. This completes primary coverage of all the
"special builds" I ever use.  If you use others, document them here, or
don't be surprised if I rip out the code for them <0.5 wink>.
2002-07-10 19:29:49 +00:00
Tim Peters 7c321a80f9 The Py_REF_DEBUG/COUNT_ALLOCS/Py_TRACE_REFS macro minefield: added
more trivial lexical helper macros so that uses of these guys expand
to nothing at all when they're not enabled.  This should help sub-
standard compilers that can't do a good job of optimizing away the
previous "(void)0" expressions.

Py_DECREF:  There's only one definition of this now.  Yay!  That
was that last one in the family defined multiple times in an #ifdef
maze.

Py_FatalError():  Changed the char* signature to const char*.

_Py_NegativeRefcount():  New helper function for the Py_REF_DEBUG
expansion of Py_DECREF.  Calling an external function cuts down on
the volume of generated code.  The previous inline expansion of abort()
didn't work as intended on Windows (the program often kept going, and
the error msg scrolled off the screen unseen).  _Py_NegativeRefcount
calls Py_FatalError instead, which captures our best knowledge of
how to abort effectively across platforms.
2002-07-09 02:57:01 +00:00
Tim Peters c6a3ff634a SF bug 578752: COUNT_ALLOCS vs heap types
Repair segfaults and infinite loops in COUNT_ALLOCS builds in the
presence of new-style (heap-allocated) classes/types.

Bugfix candidate.  I'll backport this to 2.2.  It's irrelevant in 2.1.
2002-07-08 22:11:52 +00:00
Tim Peters 4be93d0e84 Rearranged and added comments to object.h, to clarify many things
that have taken me "too long" to reverse-engineer over the years.
Vastly reduced the nesting level and redundancy of #ifdef-ery.
Took a light stab at repairing comments that are no longer true.

sys_gettotalrefcount():  Changed to enable under Py_REF_DEBUG.
It was enabled under Py_TRACE_REFS, which was much heavier than
necessary.  sys.gettotalrefcount() is now available in a
Py_REF_DEBUG-only build.
2002-07-07 19:59:50 +00:00
Tim Peters a6269a8ec5 Removed 3 unlikely #includes that were only needed for the non-gc flavor
of the trashcan code.
2002-07-07 16:52:50 +00:00
Tim Peters 803526b9e2 Trashcan cleanup: Now that cyclic gc is always there, the trashcan
mechanism is no longer evil:  it no longer plays dangerous games with
the type pointer or refcounts, and objects in extension modules can play
along too without needing to edit the core first.

Rewrote all the comments to explain this, and (I hope) give clear
guidance to extension authors who do want to play along.  Documented
all the functions.  Added more asserts (it may no longer be evil, but
it's still dangerous <0.9 wink>).  Rearranged the generated code to
make it clearer, and to tolerate either the presence or absence of a
semicolon after the macros.  Rewrote _PyTrash_destroy_chain() to call
tp_dealloc directly; it was doing a Py_DECREF again, and that has all
sorts of obscure distorting effects in non-release builds (Py_DECREF
was already called on the object!).  Removed Christian's little "embedded
change log" comments -- that's what checkin messages are for, and since
it was impossible to correlate the comments with the code that changed,
I found them merely distracting.
2002-07-07 05:13:56 +00:00
Tim Peters 943382c8e5 Removed WITH_CYCLE_GC #ifdef-ery. Holes:
+ I'm not sure what to do about configure.in.  Left it alone.

+ Ditto pyexpat.c.  Fred or Martin will know what to do.
2002-07-07 03:59:34 +00:00