[issue30907] speed up comparisons to self for built-in containers

2017-07-21 Thread wouter bolsterlee
Changes by wouter bolsterlee : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___

[issue30907] speed up comparisons to self for built-in containers

2017-07-21 Thread Tim Peters
Tim Peters added the comment: Victor, this part of the docs explains what you're seeing; scroll down to the """ In enforcing reflexivity of elements, the comparison of collections assumes that for a collection element x, x == x is always true ... """ part.

[issue30907] speed up comparisons to self for built-in containers

2017-07-21 Thread STINNER Victor
STINNER Victor added the comment: I never understood how container comparison works. >>> nan = float("nan") >>> [nan] == [nan] True >>> (nan,) == (nan,) True >>> nan == nan False >>> nan is nan True I picked the float NaN because it's one of the weirdest object in Python: it's not equal to

[issue30907] speed up comparisons to self for built-in containers

2017-07-21 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: I don't have any objections to closing this. The net benefit is contradictory, the maintenance cost is not zero. In many performance important cases (dictionary lookup, searching in sequences) the identity already is checked before calling the comparison

[issue30907] speed up comparisons to self for built-in containers

2017-07-21 Thread Raymond Hettinger
Raymond Hettinger added the comment: Any objections to closing this? -- ___ Python tracker ___ ___

[issue30907] speed up comparisons to self for built-in containers

2017-07-14 Thread Tim Peters
Tim Peters added the comment: Ya, prior to now ;-) there's generally been some cost-benefit thought given to these things. Strings and ints are immutable and some values of each are uniquely interned, so the case of identity is more than just plausible. It happens often. I'd guess that the

[issue30907] speed up comparisons to self for built-in containers

2017-07-14 Thread Mark Dickinson
Mark Dickinson added the comment: > On other hand, this optimization already is implemented for integers, > strings, bytes and slices. Probably for good reasons, though, that don't necessarily apply to general containers / other objects. I can see the possible value for strings and bytes,

[issue30907] speed up comparisons to self for built-in containers

2017-07-13 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: The main drawback of this optimization perhaps is not tiny runtime overhead in common case, but the complication of the code. It adds at least 6 or 8 lines to every rich compare implementation. On other hand, this optimization already is implemented for

[issue30907] speed up comparisons to self for built-in containers

2017-07-13 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: First, few comments about the code. 1) The condition "a == b" is enough. No need to test "PyDict_CheckExact(a)" and like. 2) This fast path can be used only for Py_EQ and Py_NE. For other operations it can change the behavior. This is common approach of

[issue30907] speed up comparisons to self for built-in containers

2017-07-13 Thread Tim Peters
Tim Peters added the comment: Measuring in isolation (like with, e.g., timeit) isn't really interesting. Then everything is in L1 cache, branches are 100% predictable (because they take the same branch over & over for the duration of the test), and second-order effects on _other_ code are

[issue30907] speed up comparisons to self for built-in containers

2017-07-13 Thread Wouter Bolsterlee
Wouter Bolsterlee added the comment: fwiw, "if (PyDict_CheckExact(a) && a == b)" amounts to two pointer comparisons, the overhead of which is too small to measure. (i tried.) -- ___ Python tracker

[issue30907] speed up comparisons to self for built-in containers

2017-07-12 Thread Tim Peters
Tim Peters added the comment: Just noting that every special code path "at the start" doesn't just speed the case it's aiming at, it also _slows_ every case that doesn't pass the new tests. It takes time to fail the new tests. So it usually makes things slower overall, unless the new thing

[issue30907] speed up comparisons to self for built-in containers

2017-07-12 Thread Raymond Hettinger
Raymond Hettinger added the comment: This seems like it optimizes an irrelevant use case, comparing a container to itself. I don't think this is likely to benefit any existing code, so it would be better not to add more code clutter/complexity with another special case code path unless

[issue30907] speed up comparisons to self for built-in containers

2017-07-12 Thread Raymond Hettinger
Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___

[issue30907] speed up comparisons to self for built-in containers

2017-07-12 Thread Wouter Bolsterlee
Changes by Wouter Bolsterlee : -- pull_requests: +2745 ___ Python tracker ___ ___

[issue30907] speed up comparisons to self for built-in containers

2017-07-12 Thread Serhiy Storchaka
Changes by Serhiy Storchaka : -- nosy: +rhettinger ___ Python tracker ___ ___

[issue30907] speed up comparisons to self for built-in containers

2017-07-12 Thread Wouter Bolsterlee
New submission from Wouter Bolsterlee: when comparing instances of the built-in container types (dict, list, and others) python assumes that "identity implies equality". this is documented (and assumed) behaviour: "In enforcing reflexivity of elements, the comparison of collections assumes