summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* x_mul(): This failed to normalize its result.Tim Peters2002-08-121-6/+18
| | | | | | | | | | | | | | | | | | | | | | k_mul(): This didn't allocate enough result space when one input had more than twice as many bits as the other. This was partly hidden by that x_mul() didn't normalize its result. The Karatsuba recurrence is pretty much hosed if the inputs aren't roughly the same size. If one has at least twice as many bits as the other, we get a degenerate case where the "high half" of the smaller input is 0. Added a special case for that, for speed, but despite that it helped, this can still be much slower than the "grade school" method. It seems to take a really wild imbalance to trigger that; e.g., a 2**22-bit input times a 1000-bit input on my box runs about twice as slow under k_mul than under x_mul. This still needs to be addressed. I'm also not sure that allocating a->ob_size + b->ob_size digits is enough, given that this is computing k = (ah+al)*(bh+bl) instead of k = (ah-al)*(bl-bh); i.e., it's certainly enough for the final result, but it's vaguely possible that adding in the "artificially" large k may overflow that temporarily. If so, an assert will trigger in the debug build, but we'll probably compute the right result anyway(!).
* Introduced helper functions v_iadd and v_isub, for in-place digit-vectorTim Peters2002-08-121-29/+75
| | | | | | | addition and subtraction. Reworked the tail end of k_mul() to use them. This saves oodles of one-shot longobject allocations (this is a triply- recursive routine, so saving one allocation in the body saves 3**n allocations at depth n; we actually save 2 allocations in the body).
* k_mul(): Repaired another typo in another comment.Tim Peters2002-08-121-1/+1
|
* k_mul(): Repaired typo in comment.Tim Peters2002-08-121-1/+1
|
* Cautious introduction of a patch that started fromTim Peters2002-08-121-85/+264
| | | | | | | | SF 560379: Karatsuba multiplication. Lots of things were changed from that. This needs a lot more testing, for correctness and speed, the latter especially when bit lengths are unbalanced. For now, the Karatsuba code gets invoked if and only if envar KARAT exists.
* int_lshift(): Simplified/sped overflow-checking.Tim Peters2002-08-111-4/+2
|
* Use a better check for overflow from a<<b.Guido van Rossum2002-08-111-2/+4
|
* Add C API PyUnicode_FromOrdinal() which exposes unichr() at C level.Marc-André Lemburg2002-08-111-1/+55
| | | | | | | u'%c' will now raise a ValueError in case the argument is an integer outside the valid range of Unicode code point ordinals. Closes SF bug #593581.
* Implement stage B0 of PEP 237: add warnings for operations thatGuido van Rossum2002-08-113-3/+41
| | | | | | | | | | currently return inconsistent results for ints and longs; in particular: hex/oct/%u/%o/%x/%X of negative short ints, and x<<n that either loses bits or changes sign. (No warnings for repr() of a long, though that will also change to lose the trailing 'L' eventually.) This introduces some warnings in the test suite; I'll take care of those later.
* Fixed new typos, added a little info about ~sort versus "hint"s.Tim Peters2002-08-101-4/+10
|
* Disallow class assignment completely unless both old and new are heapGuido van Rossum2002-08-101-6/+9
| | | | | types. This prevents nonsense like 2.__class__ = bool or True.__class__ = int.
* 1. Combined the base and length arrays into a single array of structs.Tim Peters2002-08-102-53/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* The samplesort-vs-mergesort #-of-comparisons comparisons were capturedTim Peters2002-08-101-24/+24
| | | | | | | | before %sort was introduced. Redid them (the numbers change, but the conclusions don't). Also did the samplesort counts with the released 2.2.1, as they're slightly different under the last CVS 2.3 samplesort (some higher, some lower -- CVS had been changed to stop doing the special-case business on recursive samplesort calls).
* Add support for the iterator protocol to weakref proxy objects.Fred Drake2002-08-091-38/+64
| | | | Part of fixing SF bug #591704.
* Unicode replace() method with empty pattern argument should fail, likeGuido van Rossum2002-08-091-0/+5
| | | | it does for 8-bit strings.
* Only call sq_repeat if the object does not have a nb_multiply slot. OneNeil Schemenauer2002-08-091-6/+8
| | | | | | | example of where this changes behavior is when a new-style instance defines '__mul__' and '__rmul__' and is multiplied by an int. Before the change the '__rmul__' method is never called, even if the int is the left operand.
* Repaired a braino in the description of bad minrun values.Tim Peters2002-08-091-3/+3
|
* Major speedup for new-style class creation. Turns out there was someGuido van Rossum2002-08-091-0/+22
| | | | | | | | | | | | trampolining going on with the tp_new descriptor, where the inherited PyType_GenericNew was overwritten with the much slower slot_tp_new which would end up calling tp_new_wrapper which would eventually call PyType_GenericNew. Add a special case for this to update_one_slot(). XXX Hope there isn't a loophole in this. I'll buy the first person to point out a bug in the reasoning a beer. Backport candidate (but I won't do it).
* Moved special case for tuples from iterobject.c toRaymond Hettinger2002-08-092-25/+123
| | | | | | tupleobject.c. Makes the code in iterobject.c cleaner and speeds-up the general case by not checking for tuples everytime. SF Patch #592065.
* Significant speedup in new-style object creation: in slot_tp_new(),Guido van Rossum2002-08-081-1/+8
| | | | | | | | | intern the string "__new__" so we can call PyObject_GetAttr() rather than PyObject_GetAttrString(). (Though it's a mystery why slot_tp_new is being called when a class doesn't define __new__. I'll look into that tomorrow.) 2.2 backport candidate (but I won't do it).
* A modest speedup of object deallocation. call_finalizer() did ratherGuido van Rossum2002-08-081-66/+70
| | | | | | | | | | | | | | | a lot of work: it had to save and restore the current exception around a call to lookup_maybe(), because that could fail in rare cases, and most objects don't have a __del__ method, so the whole exercise was usually a waste of time. Changed this to cache the __del__ method in the type object just like all other special methods, in a new slot tp_del. So now subtype_dealloc() can test whether tp_del is NULL and skip the whole exercise if it is. The new slot doesn't need a new flag bit: subtype_dealloc() is only called if the type was dynamically allocated by type_new(), so it's guaranteed to have all current slots. Types defined in C cannot fill in tp_del with a function of their own, so there's no corresponding "wrapper". (That functionality is already available through tp_dealloc.)
* Added info about highwater heap-memory use for the sortperf.py tests; + aTim Peters2002-08-081-3/+31
| | | | couple of minor edits elsewhere.
* PyList_Reverse(): This was leaking a reference to Py_None on every call.Tim Peters2002-08-081-1/+4
| | | | | 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.
* Fix a subtle bug in the trashcan code I added yesterday toGuido van Rossum2002-08-071-2/+3
| | | | | | | | | | | | | | | | | | | | | | | subtype_dealloc(). When call_finalizer() failed, it would return without going through the trashcan end macro, thereby unbalancing the trashcan nesting level counter, and thereby defeating the test case (slottrash() in test_descr.py). This in turn meant that the assert in the GC_UNTRACK macro wasn't triggered by the slottrash() test despite a bug in the code: _PyTrash_destroy_chain() calls the dealloc routine with an object that's untracked, and the assert in the GC_UNTRACK macro would fail on this; but because of an earlier test that resurrects an object, causing call_finalizer() to fail and the trashcan nesting level to be unbalanced, so _PyTrash_destroy_chain() was never called. Calling the slottrash() test in isolation *did* trigger the assert, however. So the fix is twofold: (1) call the GC_UnTrack() function instead of the GC_UNTRACK macro, because the function is safe when the object is already untracked; (2) when call_finalizer() fails, jump to a label that exits through the trashcan end macro, keeping the trashcan nesting balanced.
* Replace abort with Py_FatalError.Martin v. Löwis2002-08-071-1/+1
|
* Make more functions staticNeal Norwitz2002-08-061-2/+2
|
* Make readahead functions staticNeal Norwitz2002-08-061-5/+8
|
* Fix SF bug 574207 (chained __slots__ dealloc segfault).Guido van Rossum2002-08-061-10/+52
| | | | | | | | | | | This is inspired by SF patch 581742 (by Jonathan Hogg, who also submitted the bug report, and two other suggested patches), but separates the non-GC case from the GC case to avoid testing for GC several times. Had to fix an assert() from call_finalizer() that asserted that the object wasn't untracked, because it's possible that the object isn't GC'ed!
* PyUnicode_Contains(): The memcmp() call didn't take into account theBarry Warsaw2002-08-061-1/+1
| | | | width of Py_UNICODE. Good catch, MAL.
* Committing patch #591250 which provides "str1 in str2" when str1 is aBarry Warsaw2002-08-062-26/+39
| | | | string of longer than 1 character.
* SF patch 580331 by Oren Tirosh: make file objects their own iterator.Guido van Rossum2002-08-061-31/+130
| | | | | | | | | | | | | | | | | | | | | | For a file f, iter(f) now returns f (unless f is closed), and f.next() is similar to f.readline() when EOF is not reached; however, f.next() uses a readahead buffer that messes up the file position, so mixing f.next() and f.readline() (or other methods) doesn't work right. Calling f.seek() drops the readahead buffer, but other operations don't. The real purpose of this change is to reduce the confusion between objects and their iterators. By making a file its own iterator, it's made clearer that using the iterator modifies the file object's state (in particular the current position). A nice side effect is that this speeds up "for line in f:" by not having to use the xreadlines module. The f.xreadlines() method is still supported for backwards compatibility, though it is the same as iter(f) now. (I made some cosmetic changes to Oren's code, and added a test for "file closed" to file_iternext() and file_iter().)
* SF 582071 clarified the .split() method's docstring to note that sep=NoneRaymond Hettinger2002-08-051-2/+2
| | | | will trigger splitting on any whitespace.
* Sped the usual case for sorting by calling PyObject_RichCompareBoolTim Peters2002-08-041-10/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SF bug 590366: Small typo in listsort:ParseTupleTim Peters2002-08-031-1/+1
| | | | The PyArg_ParseTuple() error string still said "msort". Changed to "sort".
* Tim found that once test_longexp has run, test_sort takes very muchGuido van Rossum2002-08-011-5/+3
| | | | | | | | | | | | 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. :-)
* SF patch 588728 (Nathan Srebro).Guido van Rossum2002-08-011-0/+18
| | | | | | | | The __delete__ method wrapper for descriptors was not supported (I added a test, too.) 2.2 bugfix candidate.
* Replaced samplesort with a stable, adaptive mergesort.Tim Peters2002-08-011-406/+772
|
* Checking in the doc file for "timsort". There's way too much here toTim Peters2002-08-011-0/+618
| | | | | stuff into code comments, and lots of it is going to be useful again (but hard to predict exactly which parts of it ...).
* SF patch #587889, fix memory leak of tp_docNeal Norwitz2002-07-301-0/+1
|
* Fix forMichael W. Hudson2002-07-291-3/+8
| | | | | | [ 587875 ] crash on deleting extended slice The array code got simpler, always a good thing!
* Excise DL_IMPORT/EXPORT from object.h, and related files. This patchMark Hammond2002-07-291-2/+2
| | | | | also adds 'extern' to PyAPI_DATA rather than at each declaration, as discussed with Tim and Guido.
* Fix the problem of not raising a TypeError exception when doing:Neal Norwitz2002-07-281-8/+8
| | | | | | | | '%g' % '1' '%d' % '1' Add a test for these conditions Fix the test so that if not exception is raise, this is a failure
* Patch #574867: Correct list.extend docstring.Martin v. Löwis2002-07-281-1/+1
|
* SF patch #577031, remove PyArg_Parse() since it's deprecatedNeal Norwitz2002-07-281-2/+8
|
* Patch #554716: Use __va_copy where available.Martin v. Löwis2002-07-282-0/+8
|
* tighten up the unicode object's docstring a tadSkip Montanaro2002-07-261-2/+2
|
* Don't be so hasty. If PyInt_AsLong() raises an error, don't set ValueError.Jeremy Hylton2002-07-251-0/+2
|
* Complain if __len__() returns < 0, just like classic classes.Jeremy Hylton2002-07-251-0/+5
| | | | | | Fixes SF bug #575773. Bug fix candidate.
* Silly typo. Not sure how that got in.Michael W. Hudson2002-07-191-1/+1
|
* A few days ago, Guido said (in the thread "[Python-Dev] PythonMichael W. Hudson2002-07-191-1/+34
| | | | | | | | 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.
generated by cgit v0.12 at 2024-11-27 23:34:14 (GMT)