Commit Graph

145 Commits

Author SHA1 Message Date
Tim Peters b9099c3df4 SF patch 637176: list.sort crasher
Armin Rigo's Draconian but effective fix for

SF bug 453523: list.sort crasher

slightly fiddled to catch more cases of list mutation.  The dreaded
internal "immutable list type" is gone!  OTOH, if you look at a list
*while* it's being sorted now, it will appear to be empty.  Better
than a core dump.
2002-11-12 22:08:10 +00:00
Neal Norwitz 03b109afc0 Use PyOS_snprintf() instead of sprintf and wrap the long line 2002-11-05 22:41:37 +00:00
Michael W. Hudson 5da854fe51 This is Alex Martelli's patch
[ 633870 ] allow any seq assignment to a list slice

plus a very silly little test case of my own.
2002-11-05 17:38:05 +00:00
Guido van Rossum bfa5a14adb Darn! Don't divide by zero. Bad fix. :-) 2002-10-11 23:39:35 +00:00
Guido van Rossum a5c0e6d6c8 Add checks for size overflow on list*n, list+list, tuple+tuple.
Will backport.
2002-10-11 21:05:56 +00:00
Neal Norwitz bb9c5f5032 PyObject_RichCompareBool() already returns -1, 0, or 1, so return its value 2002-09-05 21:32:55 +00:00
Raymond Hettinger aae5999b44 Micro-optimization for list_contains. Factored double if test
out of the loop.
2002-09-05 14:23:49 +00:00
Tim Peters e05f65a0c6 1. Combined the base and length arrays into a single array of structs.
This is friendlier for caches.

2. Cut MIN_GALLOP to 7, but added a per-sort min_gallop vrbl that adapts
   the "get into galloping mode" threshold higher when galloping isn't
   paying, and lower when it is.  There's no known case where this hurts.
   It's (of course) neutral for /sort, \sort and =sort.  It also happens
   to be neutral for !sort.  It cuts a tiny # of compares in 3sort and +sort.
   For *sort, it reduces the # of compares to better than what this used to
   do when MIN_GALLOP was hardcoded to 10 (it did about 0.1% more *sort
   compares before, but given how close we are to the limit, this is "a
   lot"!).  %sort used to do about 1.5% more compares, and ~sort about
   3.6% more.  Here are exact counts:

 i    *sort    3sort    +sort    %sort    ~sort    !sort
15   449235    33019    33016    51328   188720    65534  before
     448885    33016    33007    50426   182083    65534  after
      0.08%    0.01%    0.03%    1.79%    3.65%    0.00%  %ch from after

16   963714    65824    65809   103409   377634   131070
     962991    65821    65808   101667   364341   131070
      0.08%    0.00%    0.00%    1.71%    3.65%    0.00%

17  2059092   131413   131362   209130   755476   262142
    2057533   131410   131361   206193   728871   262142
      0.08%    0.00%    0.00%    1.42%    3.65%    0.00%

18  4380687   262440   262460   421998  1511174   524286
    4377402   262437   262459   416347  1457945   524286
      0.08%    0.00%    0.00%    1.36%    3.65%    0.00%

19  9285709   524581   524634   848590  3022584  1048574
    9278734   524580   524633   837947  2916107  1048574
      0.08%    0.00%    0.00%    1.27%    3.65%    0.00%

20 19621118  1048960  1048942  1715806  6045418  2097150
   19606028  1048958  1048941  1694896  5832445  2097150
      0.08%    0.00%    0.00%    1.23%    3.65%    0.00%

3. Added some key asserts I overlooked before.

4. Updated the doc file.
2002-08-10 05:21:15 +00:00
Tim Peters 6063e2615f PyList_Reverse(): This was leaking a reference to Py_None on every call.
I believe I introduced this bug when I refactored the reversal code so
that the mergesort could use it too.  It's not a problem on the 2.2 branch.
2002-08-08 01:06:39 +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
Tim Peters a64dc245ac Replaced samplesort with a stable, adaptive mergesort. 2002-08-01 02:13:36 +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
Martin v. Löwis 673c0a2247 Patch #574867: Correct list.extend docstring. 2002-07-28 16:35:57 +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 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 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
Guido van Rossum 5086e49a6e Make list_iter() really static. 2002-07-16 15:56:52 +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
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
Michael W. Hudson 9c14badc5f Fix the bug described in
http://mail.python.org/pipermail/python-dev/2002-June/025461.html

with test cases.

Also includes extended slice support for arrays, which I thought I'd
already checked in but obviously not.
2002-06-19 15:44:15 +00:00
Neal Norwitz 2c2e827029 Missed one use of new PyDoc_STRVAR macro 2002-06-14 02:04:18 +00:00
Neal Norwitz 35fc7606f0 SF #561244 Micro optimizations
Convert loops to memset()s.
2002-06-13 21:11:11 +00:00
Martin v. Löwis 14f8b4cfcb Patch #568124: Add doc string macros. 2002-06-13 20:33:02 +00:00
Guido van Rossum 75a20b19ef Fold remaining long lines. 2002-06-11 12:22:28 +00:00
Michael W. Hudson 5efaf7eac8 This is my nearly two year old patch
[ 400998 ] experimental support for extended slicing on lists

somewhat spruced up and better tested than it was when I wrote it.

Includes docs & tests.  The whatsnew section needs expanding, and arrays
should support extended slices -- later.
2002-06-11 10:55:12 +00:00
Tim Peters 93b2cc4e97 A bogus assert in the new listiter code prevented starting Python in a
debug build.  Repaired that, and rewrote other parts to reduce
long-winded casting.
2002-06-01 05:22:55 +00:00
Raymond Hettinger 14bd6de0ec SF 560736. Optimize list iteration by filling the tp_iter slot. 2002-05-31 21:40:38 +00:00
Neal Norwitz d4e5be5340 Closes: #556025 seg fault when doing list(xrange(1e9))
A MemoryError is now raised when the list cannot be created.
There is a test, but as the comment says, it really only
works for 32 bit systems.  I don't know how to improve
the test for other systems (ie, 64 bit or systems
where the data size != addressable size,
e.g. 64 bit data, but 48 bit addressable memory)
2002-05-22 23:19:17 +00:00
Neil Schemenauer 99b5d28467 PyObject_GC_Del can now be used as a function designator. 2002-04-12 02:44:22 +00:00
Guido van Rossum ff413af605 This is Neil's fix for SF bug 535905 (Evil Trashcan and GC interaction).
The fix makes it possible to call PyObject_GC_UnTrack() more than once
on the same object, and then move the PyObject_GC_UnTrack() call to
*before* the trashcan code is invoked.

BUGFIX CANDIDATE!
2002-03-28 20:34:59 +00:00
Guido van Rossum dbb53d9918 Fix of SF bug #475877 (Mutable subtype instances are hashable).
Rather than tweaking the inheritance of type object slots (which turns
out to be too messy to try), this fix adds a __hash__ to the list and
dict types (the only mutable types I'm aware of) that explicitly
raises an error.  This has the advantage that list.__hash__([]) also
raises an error (previously, this would invoke object.__hash__([]),
returning the argument's address); ditto for dict.__hash__.

The disadvantage for this fix is that 3rd party mutable types aren't
automatically fixed.  This should be added to the rules for creating
subclassable extension types: if you don't want your object to be
hashable, add a tp_hash function that raises an exception.

Also, it's possible that I've forgotten about other mutable types for
which this should be done.
2001-12-03 16:32:18 +00:00
Guido van Rossum 9475a2310d Enable GC for new-style instances. This touches lots of files, since
many types were subclassable but had a xxx_dealloc function that
called PyObject_DEL(self) directly instead of deferring to
self->ob_type->tp_free(self).  It is permissible to set tp_free in the
type object directly to _PyObject_Del, for non-GC types, or to
_PyObject_GC_Del, for GC types.  Still, PyObject_DEL was a tad faster,
so I'm fearing that our pystone rating is going down again.  I'm not
sure if doing something like

void xxx_dealloc(PyObject *self)
{
	if (PyXxxCheckExact(self))
		PyObject_DEL(self);
	else
		self->ob_type->tp_free(self);
}

is any faster than always calling the else branch, so I haven't
attempted that -- however those types whose own dealloc is fancier
(int, float, unicode) do use this pattern.
2001-10-05 20:51:39 +00:00
Tim Peters 52e0717215 Give the internal immutable list type .extend and .pop methods (they
"should have" been added here when they were added to lists).
2001-08-30 06:15:32 +00:00
Neil Schemenauer e83c00efd0 Use new GC API. 2001-08-29 23:54:21 +00:00
Martin v. Löwis e3eb1f2b23 Patch #427190: Implement and use METH_NOARGS and METH_O. 2001-08-16 13:15:00 +00:00
Tim Peters 6d6c1a35e0 Merge of descr-branch back into trunk. 2001-08-02 04:15:00 +00:00
Tim Peters 6ee4234802 SF bug #439104: Tuple richcompares has code-typo.
Symptom:  (1, 2, 3) <= (1, 2) returned 1.
This was already fixed in CVS for tuples, but an isomorphic error was in
the list richcompare code.
2001-07-06 17:45:43 +00:00
Tim Peters a7259597f1 SF bug 433228: repr(list) woes when len(list) big.
Gave Python linear-time repr() implementations for dicts, lists, strings.
This means, e.g., that repr(range(50000)) is no longer 50x slower than
pprint.pprint() in 2.2 <wink>.

I don't consider this a bugfix candidate, as it's a performance boost.

Added _PyString_Join() to the internal string API.  If we want that in the
public API, fine, but then it requires runtime error checks instead of
asserts.
2001-06-16 05:11:17 +00:00
Tim Peters 1af03e98d9 Change list.extend() error msgs and NEWS to reflect that list.extend()
now takes any iterable argument, not only sequences.

NEEDS DOC CHANGES -- but I don't think we settled on a concise way to
say this stuff.
2001-05-26 19:37:54 +00:00
Tim Peters 442914d265 Cruft cleanup: removed the #ifdef'ery in support of compiling to allow
multi-argument list.append(1, 2, 3) (as opposed to .append((1,2,3))).
2001-05-26 05:50:03 +00:00
Tim Peters 65b8b84839 roundupsize() and friends: fiddle over-allocation strategy for list
resizing.

Accurate timings are impossible on my Win98SE box, but this is obviously
faster even on this box for reasonable list.append() cases.  I give
credit for this not to the resizing strategy but to getting rid of integer
multiplication and divsion (in favor of shifting) when computing the
rounded-up size.

For unreasonable list.append() cases, Win98SE now displays linear behavior
for one-at-time appends up to a list with about 35 million elements.  Then
it dies with a MemoryError, due to fatally fragmented *address space*
(there's plenty of VM available, but by this point Win9X has broken user
space into many distinct heaps none of which has enough contiguous space
left to resize the list, and for whatever reason Win9x isn't coalescing
the dead heaps).  Before the patch it got a MemoryError for the same
reason, but once the list reached about 2 million elements.

Haven't yet tried on Win2K but have high hopes extreme list.append()
will be much better behaved now (NT & Win2K didn't fragment address space,
but suffered obvious quadratic-time behavior before as lists got large).

For other systems I'm relying on common sense:  replacing integer * and /
by << and >> can't plausibly hurt, the number of function calls hasn't
changed, and the total operation count for reasonably small lists is about
the same (while the operations are cheaper now).
2001-05-26 05:28:40 +00:00
Guido van Rossum b86c549c7c Fix core dump whenever PyList_Reverse() was called.
This fixes SF bug #132008, reported by Warren J. Hack.

The copyright for this patch (and this patch only) belongs to CNRI, as
part of the (yet to be issued) 1.6.1 release.

This is now checked into the HEAD branch.  Tim will check in a test
case to check for this specific bug, and an assertion in
PyArgs_ParseTuple() to catch similar bugs in the future.
2001-02-12 22:06:02 +00:00