| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Replace sprintf message with a constant message string -- this error
message ran on every invocation except straight deletions but it was
only needed when the rhs was not iterable. The message was also
out-of-date and did not reflect that iterable arguments were allowed.
* For inner loops that do not make ref count adjustments, use memmove()
for fast copying and better readability.
* For inner loops that do make ref count adjustments, speed them up by
factoring out the constant structure reference and using vitem[] instead.
|
|
|
|
|
|
| |
and list.extend(). Factoring the inner loops to remove the constant
structure references and fixed offsets gives speedups ranging from
20% to 30%.
|
|
|
|
|
|
|
|
| |
* Using addition instead of substraction on array indices allows the
compiler to use a fast addressing mode. Saves about 10%.
* Using PyTuple_GET_ITEM and PyList_SET_ITEM is about 7% faster than
PySequenceFast_GET_ITEM which has to make a list check on every pass.
|
|
|
|
|
| |
for types other than PyInt being accepted for the optional argument.
(Spotted by Neal Norwitz.)
|
|
|
|
| |
arguments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
utilization, and speed:
* Moved the responsibility for emptying the previous list from list_fill
to list_init.
* Replaced the code in list_extend with the superior code from list_fill.
* Eliminated list_fill.
Results:
* list.extend() no longer creates an intermediate tuple except to handle
the special case of x.extend(x). The saves memory and time.
* list.extend(x) runs
5 to 10% faster when x is a list or tuple
15% faster when x is an iterable not defining __len__
twice as fast when x is an iterable defining __len__
* the code is about 15 lines shorter and no longer duplicates
functionality.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Py2.3 approach overallocated small lists by up to 8 elements.
The last checkin would limited this to one but slowed down (by 20 to 30%)
the creation of small lists between 3 to 8 elements.
This tune-up balances the two, limiting overallocation to 3 elements
(significantly reducing space consumption from Py2.3) and running faster
than the previous checkin.
The first part of the growth pattern (0, 4, 8, 16) neatly meshes with
allocators that trigger data movement only when crossing a power of two
boundary. Also, then even numbers mesh well with common data alignments.
|
| |
|
|
|
|
| |
More than doubles its speed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
realloc(). This is achieved by tracking the overallocation size in a new
field and using that information to skip calls to realloc() whenever
possible.
* Simplified and tightened the amount of overallocation. For larger lists,
this overallocates by 1/8th (compared to the previous scheme which ranged
between 1/4th to 1/32nd over-allocation). For smaller lists (n<6), the
maximum overallocation is one byte (formerly it could be upto eight bytes).
This saves memory in applications with large numbers of small lists.
* Eliminated the NRESIZE macro in favor of a new, static list_resize function
that encapsulates the resizing logic. Coverting this back to macro would
give a small (under 1%) speed-up. This was too small to warrant the loss
of readability, maintainability, and de-coupling.
* Some functions using NRESIZE had grown unnecessarily complex in their
efforts to bend to the macro's calling pattern. With the new list_resize
function in place, those other functions could be simplified. That is
being saved for a separate patch.
* The ob_item==NULL check could be eliminated from the new list_resize
function. This would entail finding each piece of code that sets ob_item
to NULL and adding a new line to invalidate the overallocation tracking
field. Rather than impose a new requirement on other pieces of list code,
it was preferred to leave the NULL check in place and retain the benefits
of decoupling, maintainability and information hiding (only PyList_New()
and list_sort() need to know about the new field). This approach also
reduces the odds of breaking an extension module.
(Collaborative effort by Raymond Hettinger, Hye-Shik Chang, Tim Peters,
and Armin Rigo.)
|
|
|
|
| |
patch.
|
| |
|
|
|
|
|
|
|
|
| |
Formerly, length data fetched from sequence objects.
Now, any object that reports its length can benefit from pre-sizing.
On one sample timing, it gave a threefold speedup for list(s) where s
was a set object.
|
| |
|
|
|
|
|
|
| |
The special-case code that was removed could return a value indicating
success but leave an exception set. test_fileinput failed in a debug
build as a result.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which can be reviewed via
http://coding.derkeiler.com/Archive/Python/comp.lang.python/2003-12/1011.html
Duncan Booth investigated, and discovered that an "optimisation" was
in fact a pessimisation for small numbers of elements in a source list,
compared to not having the optimisation, although with large numbers
of elements in the source list the optimisation was quite beneficial.
He posted his change to comp.lang.python (but not to SF).
Further research has confirmed his assessment that the optimisation only
becomes a net win when the source list has more than 100 elements.
I also found that the optimisation could apply to tuples as well,
but the gains only arrive with source tuples larger than about 320
elements and are nowhere near as significant as the gains with lists,
(~95% gain @ 10000 elements for lists, ~20% gain @ 10000 elements for
tuples) so I haven't proceeded with this.
The code as it was applied the optimisation to list subclasses as
well, and this also appears to be a net loss for all reasonable sized
sources (~80-100% for up to 100 elements, ~20% for more than 500
elements; I tested up to 10000 elements).
Duncan also suggested special casing empty lists, which I've extended
to all empty sequences.
On the basis that list_fill() is only ever called with a list for the
result argument, testing for the source being the destination has
now happens before testing source types.
|
|
|
|
| |
sorted() becomes a regular function instead of a classmethod.
|
|
|
|
|
| |
* Used the flag to optimize set.__contains__(), dict.__contains__(),
dict.__getitem__(), and list.__getitem__().
|
|
|
|
|
| |
deallocating garbage pointers; saved_ob_item and empty_ob_item.
(Reviewed by Raymond Hettinger)
|
|
|
|
|
|
| |
can run" bugs as discussed in
[ 848856 ] couple of new list.sort bugs
|
|
|
|
|
| |
an exception raised by the key function.
(Suggested by Michael Hudson.)
|
|
|
|
| |
is exhausted.
|
| |
|
| |
|
|
|
|
| |
Also fix use of n for two different variables in two different blocks.
|
| |
|
| |
|
|
|
|
|
|
|
| |
key provides C support for the decorate-sort-undecorate pattern.
reverse provide a stable sort of the list with the comparisions reversed.
* Amended the docs to guarantee sort stability.
|
|
|
|
|
|
| |
Fix, by not using n at all in that case.
Needs to be applied to release23-maint, too.
|
|
|
|
|
|
| |
Check for a[:] = a _before_ calling PySequence_Fast on a.
release23-maint candidate
Reference leak doesn't happen with head of release22-maint.
|
|
|
|
| |
huge start and stop arguments. Add tests.
|
|
|
|
|
| |
- don't use min() and max()
- interpret negative start/stop argument like negative slice indices
|
|
|
|
| |
Also, modified UserList.index() to match and expanded the related tests.
|
|
|
|
| |
Fulfilled request to special case repetitions of lists of length 0 or 1.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverted a Py2.3b1 change to iterator in subclasses of list and tuple.
They had been changed to use __getitem__ whenever it had been overriden
in the subclass.
This caused some usabilty and performance problems. Also, it was
inconsistent with the rest of python where many container methods
access the underlying object directly without first checking for
an overridden getter. Users needing a change in iterator behavior
should override it directly.
|
| |
|
|
|
|
| |
functions with different signatures.
|
|
|
|
|
|
|
|
| |
As a side issue on this bug, it was noted that list and tuple iterators
used macros to directly access containers and would not recognize
__getitem__ overrides. If the method is overridden, the patch returns
a generic sequence iterator which calls the __getitem__ method; otherwise,
it returns a high custom iterator with direct access to container elements.
|
|
|
|
|
|
| |
interpreted by slicing, so negative values count from the end of the
list. This was the only place where such an interpretation was not
placed on a list index.
|
|
|
|
|
|
| |
to more accurately describe what the function does.
Suggested by Thomas Wouters.
|
|
|
|
| |
Factors out the common case of returning self.
|
|
|
|
| |
661092.
|
|
|
|
|
|
|
| |
Obtain cleaner coding and a system wide
performance boost by using the fast, pre-parsed
PyArg_Unpack function instead of PyArg_ParseTuple
function which is driven by a format string.
|
|
|
|
| |
experimental.
|
|
|
|
|
|
| |
[ 633152 ] list slice ass ignores subtypes of list
Allow arbitrary sequences on the RHS of extended slices.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
[ 633870 ] allow any seq assignment to a list slice
plus a very silly little test case of my own.
|