Repository navigation
Calling assertEquals for moderately long list takes too long #63416
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ezio-melotti'
closed_at = None
created_at = <Date 2013-10-10.13:04:46.624>
labels = ['3.11', 'library', 'performance']
title = 'Calling assertEquals for moderately long list takes too long'
updated_at = <Date 2022-03-04.11:49:12.121>
user = 'https://bugs.python.org/JacekBzdak'bugs.python.org fields:
activity = <Date 2022-03-04.11:49:12.121>
actor = 'AlexWaygood'
assignee = 'ezio.melotti'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2013-10-10.13:04:46.624>
creator = 'Jacek.Bzdak'
dependencies = []
files = ['32033', '32105', '36144', '36292', '36295', '36330', '37001', '41824', '46573', '46574', '47921']
hgrepos = []
issue_num = 19217
keywords = ['patch', 'needs review']
message_count = 30.0
messages = ['199383', '199384', '199466', '199833', '199855', '200770', '200827', '216480', '217426', '217563', '224193', '224965', '224983', '225126', '225130', '225132', '225134', '229858', '229910', '259674', '261712', '287264', '287284', '329655', '329657', '370632', '398008', '398198', '398440', '405890']
nosy_count = 25.0
nosy_names = ['terry.reedy', 'gregory.p.smith', 'paul.moore', 'pitrou', 'rbcollins', 'tim.golden', 'ezio.melotti', 'michael.foord', 'lukasz.langa', 'zach.ware', 'serhiy.storchaka', 'Jacek.Bzdak', 'steve.dower', 'Ankur.Ankan', 'Elena.Oat', 'nnja', 'ankurankan', 'Puneeth.Chaganti', 'levkivskyi', 'Chris AtLee', 'trey', 'Eric Lafontaine', 'eamanu', 'xtreak', 'jack__d']
pr_nums = ['10034', '11204', '27434']
priority = 'high'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'resource usage'
url = 'https://bugs.python.org/issue19217'
versions = ['Python 3.11']
Activity
JacekBzdak commentedon Oct 10, 2013
Call to assertEquals(list1, list2) does not finish (takes more than couple of minutes), for lists that containt 10000 elements if all list elements are different. The same call in python2.6 finishes instanteneously.
This occours even if error message is truncated using maxDiff.
JacekBzdak commentedon Oct 10, 2013
I have attached a simple test case.
voidspace commentedon Oct 11, 2013
Ouch. Looking.
ezio-melotti commentedon Oct 14, 2013
Here's a proof of concept to fix the issue (still lacks tests and breaks one existing test).
The problem is that assertSequenceEqual computes the diff regardless of the size of the sequences, and then truncates it if it's too long. Producing the diff takes time, so checking the size of the sequences and skip the diff if they are too long solves the problem.
In the patch I used an hardcoded and arbitrary value of 30 elements -- the other attributes like maxDiff and _diffThreshold can't be used here.
The value is so low because if the sequence doesn't fit in one line, the output will list one element per line, resulting in 30+ lines of output which is not very readable IMHO. Also note that regardless of the this diff, the error message indicates what is the position of the first element that differs.
The threshold value I picked could be moved to a _seqDiffThreshold (and possibly _diffThreshold can be renamed to _strDiffThreshold).
This issue is related to bpo-11763. All other methods should be checked for similar issues.
serhiy-storchaka commentedon Oct 14, 2013
Perhaps a combination of len(pprint.pformat(seq1).splitlines()) and len(pprint.pformat(seq2).splitlines()) (minimum, maximum or production) is better metric?
JacekBzdak commentedon Oct 21, 2013
The patch works for me, thanks Ezio!
voidspace commentedon Oct 21, 2013
pprint is also likely to have performance issues. I agree with Ezio that a diff consisting of more than 30(x2) lines is not likely to be directly useful anyway.
A test for the changed behaviour would be nice.
nnja commentedon Apr 16, 2014
The cause of this has been identified as a bug in libdiff.compare(). See bpo-21253 for more information.
pitrou commentedon Apr 28, 2014
Ezio, do you intend to add a test to your patch?
ezio-melotti commentedon Apr 30, 2014
I don't think I will have time for this for a while, so if anyone wants to provide tests they are welcomed to do it.
The related bpo-11763 already has some tests, so those might be adapted for this issue.
33 remaining items
jdevries3133 commentedon Jul 28, 2021
I'm going to go ahead and submit my PR under the assumption that Lukasz will probably prefer to actually be able to review it when he takes a look at this, and additionally we haven't heard from @eamanu.
@eamanu, I'll close it if you would like to continue; just let me know!
jdevries3133 commentedon Nov 7, 2021
Hey all, I'm putting a ping on this issue. I think my fix is ready to merge, see python/issues-test-cpython#27434. Thanks for all the feedback on the PR so far!
Lenormju commentedon Jul 18, 2026
Seems like the PR #27434 was closed because performance is good enough now, the underlying perf issues having been merged over the time. Could this be closed now ?
vstinner commentedon Jul 18, 2026
Using attached unittest_scse.py script, I confirm that the issue has been fixed. I ran
git bisectwith this script and I found one change.This issue has been fixed in Python 3.14 by commit de19694: