Calling assertEquals for moderately long list takes too long #63416

JacekBzdak · 2013-10-10T13:04:47Z

BPO	19217
Nosy	@terryjreedy, @gpshead, @pfmoore, @pitrou, @rbtcollins, @tjguk, @ezio-melotti, @voidspace, @ambv, @zware, @serhiy-storchaka, @zooba, @elenaoat, @nnja, @ilevkivskyi, @treyhunner, @elafontaine, @eamanu, @tirkarthi, @jdevries3133
PRs	Fix bpo-19217: Calling assertEquals for moderately long list takes too long #10034 Fix bpo-19217: Calling assertEquals for moderately long list takes too long #11204 gh-63416: Speed up assertEqual on long sequences #27434
Files	unittest_scse.py: SCSE issue19217.diff issue19217-1.diff issue19217-2.diff issue19217-3.diff issue19217-alt.diff issue19217-profile.txt: profile output of the test case cpython-issue19217.diff: Use difflib.unified_diff instead of ndiff unittest_unified_diff.patch unified_diff.py issue_19217.diff

^{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']

JacekBzdak · 2013-10-10T13:04:46Z

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 · 2013-10-10T13:05:33Z

I have attached a simple test case.

voidspace · 2013-10-11T12:11:53Z

Ouch. Looking.

ezio-melotti · 2013-10-14T01:30:31Z

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 · 2013-10-14T09:04:44Z

Perhaps a combination of len(pprint.pformat(seq1).splitlines()) and len(pprint.pformat(seq2).splitlines()) (minimum, maximum or production) is better metric?

JacekBzdak · 2013-10-21T12:50:43Z

The patch works for me, thanks Ezio!

voidspace · 2013-10-21T18:51:10Z

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 · 2014-04-16T15:57:06Z

The cause of this has been identified as a bug in libdiff.compare(). See bpo-21253 for more information.

pitrou · 2014-04-28T22:13:23Z

Ezio, do you intend to add a test to your patch?

ezio-melotti · 2014-04-30T00:55:59Z

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.

PuneethChaganti · 2014-07-28T21:44:05Z

Hi,

The attached patch is an attempt to write tests for this issue, and get all the tests passing.

Since a new threshold has been introduced, maxDiff doesn't always make a difference and this required changing the testAssertSequenceEqualMaxDiff test. Serhiy Storchaka suggestion makes sense, since we want to be showing the diff when it is smaller than the error message being shown, but I'm not sure what's the best way to do this.

elenaoat · 2014-08-06T19:34:04Z

Attached is the patch that tries to solve the issue for the strings, tuples, lists and dictionaries. Tuples, lists and dictionaries use the same value for the threshold. There's a helper method in the tests that is generic to all mentioned types.
This issue was discussed during the Helsinki Python sprint.

ezio-melotti · 2014-08-07T03:42:08Z

Thanks Puneeth for the initial tests and Elena for expanding the fix and the tests to cover assertDictEqual too.
I reworked a bit Elena's patch to make the checks in case.py more consistent and simplified the tests.

With the attached patch, unittest_scse.py works fine, producing this output:
FF
======================================================================
FAIL: test_compare (main.SCSE)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "unittest_scse.py", line 14, in test_compare
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,[29953 chars]1, 1] != [2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,[29953 chars]2, 2]

First differing element 0:
1
2

======================================================================
FAIL: test_compare_2 (main.SCSE)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "unittest_scse.py", line 24, in test_compare_2
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] != [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2]

First differing element 9999:
1
2

----------------------------------------------------------------------
Ran 2 tests in 0.010s

FAILED (failures=2)

serhiy-storchaka · 2014-08-10T08:14:45Z

Here is alternative patch. It outputs line diff even for large sequences/dicts/strings.

With the attached patch, unittest_scse.py works fine, producing this output:

FF
======================================================================
FAIL: test_compare (main.SCSE)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "unittest_scse.py", line 14, in test_compare
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,[29953 chars]1, 1] != [2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,[29953 chars]2, 2]

First differing element 0:
1
2

- [1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
-  1,
+ [2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
+  2,
...
*** Diff is truncated.  Set self.ma
8000
xDiffItems to None to see it all.

======================================================================
FAIL: test_compare_2 (main.SCSE)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "unittest_scse.py", line 24, in test_compare_2
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] != [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2]

First differing element 9999:
1
2

1]
+ 2]

----------------------------------------------------------------------
Ran 2 tests in 1.813s

FAILED (failures=2)

serhiy-storchaka · 2014-08-10T09:17:56Z

Thanks for your comments Ezio. Yes, this patch is rather only a demo. Sorry, but I'm not very interesting in completing this patch (at least not right now). I only want to see more detailed error reports.

There are some ideas about improving diffs reporting. First, we can iterative decrease slices size until diff size become less maxDiff. And output truncated diff instead of omitting it at all. Second, we can extend difflib by functions which allow to limit a number of reported differences.

ezio-melotti · 2014-08-10T09:30:01Z

I thought some more about this, and I think we can do better.
Since _diffThreshold only affects strings, the goal of this issue is to extend the check to other types. Instead of doing this by adding more attributes and behaviors, I would like to keep things as simple and consistent as possible (since they are already quite complicated), and possibly making them even simpler.

I'll try to summarize the current situation and propose some possible solutions to achieve this goal.

Currently we have:

_diffThreshold (used to avoid computing the diff, only affects strings);
maxDiff (used to "hide" diffs that are too big, after they have been computed);

These two attributes deal with two different but related problems:

_diffThreshold tries to avoid /calculating/ expensive diffs;
maxDiff tries to avoid /printing/ big and unreadable diffs;

These are different because one acts before and the other after, but they are also related because the threshold directly affects the size of the diff.

By picking some ideas from Serhiy comments and patch, I think we should:

try to have a single threshold for all types, and use line-based counting for strings (so if the threshold is 32, this means 32 elements in a list, 32 items in a dict, 32 lines in a string);
make this threshold public, so that users can control this behavior (even though we should be careful about what we add -- we can always keep it private and expose it later);
factor out the diff computation/truncation function (like Serhiy did), and use it consistently, so that we can get rid of _truncateMessage and simplify the formatting.
if possible, try to unify the threshold and the maxDiff -- if the threshold is low the diff will be small, if it's high/None the diff will be big;

Now, doing 1) shouldn't be an issue, 2) is also doable if we agree on it, and 3) is also not a problem since these are internal functions. If we decide to go for 4) as well there are at least two options:
a) repurpose maxDiff to indicate the number of items/lines;
b) introduce a new attribute (e.g. maxDiffItems) and deprecate maxDiff;

Option a) might be doable, and even if it introduces a change in behavior it might be acceptable since it affects the output of the messages in case of failure, and I don't think anyone is relying on an exact output (also because tests shouldn't be failing). Moreover, the most common usage of maxDiff is setting it to None, and having the threshold to None means that the full diff will be computed and printed, leaving the behavior unchanged.

Thoughts?

Second, we can extend difflib by functions which allow to limit a number
of reported differences.

I was thinking about having a lazy, generator-based diffing, so we could generate as many diff lines we need and stop once we reach the threshold. I'm not sure if difflib already has something similar but anyway this is a separate issue. Also, if we unify maxDiff and the threshold we won't need this, since all that is computer is also printed.

serhiy-storchaka · 2014-08-10T09:53:51Z

try to have a single threshold for all types, and use line-based counting
for strings (so if the threshold is 32, this means 32 elements in a list,
32 items in a dict, 32 lines in a string);

You forgot about strings with few but very long lines. We should hide or
truncate too long lines, and this is not trivial issue. Actually we should
more control on difflib's machinery and use something like _common_shorten_repr
to appropriate truncate similar lines.

Option a) might be doable, and even if it introduces a change in behavior it
might be acceptable since it affects the output of the messages in case of
failure, and I don't think anyone is relying on an exact output (also
because tests shouldn't be failing). Moreover, the most common usage of
maxDiff is setting it to None, and having the threshold to None means that
the full diff will be computed and printed, leaving the behavior unchanged.

This is too much for bug fix. We should fix this issue (do not calculate diffs
between too long sequences) and preserve as much details as possible. Omitting
the diff at all when it is outputted with current code (but very slowly) is a
regression. It would be better to output truncated diff.

Then we can refactor and improve diffs reporting in other issues.

rbtcollins · 2014-10-23T07:13:23Z

A few thoughts.

Adding a new public symbol seems inappropriate here: this is a performance issue that is well predictable and we should cater for that (given difflibs current performance).

I'll note in passing that both bzr and hg have much higher performance difference algorithms that we could pick up and includes as a replacement SequenceMatcher, which might significantly reduce the threshold at which we need to default-cap things - but such a threshold will still exist.

I totally agree that _diffThreshold should apply to non-string sequences - anything where we're going to hit high-order complexity outputting the difference. That said, I speculate that perhaps we'd be better off outputting both objects in some structured fashion and letting a later process render them (for things like CI systems and test databases, where fidelity of reproduction is more important than having the output fit on one screen. This is a different issue though and something we should revisit later.

That suggests to me though that the largest diff we output should be chosen based on the textual representation of the diff - we're doing it for human readability. Whereas the threshold for calculating a diff at all should be based on performance. It can be very expensive to calculate a diff on large sequences, but the diff might be much much larger than the sequence length indicates [because each item in the sequence may be very large]. Perhaps thats over thinking it?

Anyhow- short term, surely just making the threshold apply to any sequenced type is sufficient to fix the bug?

rbtcollins · 2014-10-24T03:24:18Z

Oh, I got a profile from the test case for my own interest.

6615 seconds ..

some highlights that jumped out at me

20001    0.127    0.000 6610.025    0.330 difflib.py:868(compare)

which means we're basically using ndiff, which is cubic rather than quadratic - the same performance issue the html module had.

I think we'll probably make a better tradeoff by using unified_diff instead which is quadratic.

ChrisAtLee · 2016-02-05T16:48:16Z

Switching this to unified_diff allows the test case to finish nearly instantly.

The downside is that the output is changed in the case of a difference found:

FF
======================================================================
FAIL: test_compare (main.SCSE)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "test_case.py", line 14, in test_compare
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,[29953 chars]1, 1] != [2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,[29953 chars]2, 2]

First differing element 0:
1
2

Diff is 100034 characters long. Set self.maxDiff to None to see it.

======================================================================
FAIL: test_compare_2 (main.SCSE)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "test_case.py", line 24, in test_compare_2
    self.assertEqual(arr1, arr2)
AssertionError: Lists differ: [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1] != [1, 1[29932 chars] 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2]

First differing element 9999:
1
2

--- 
+++ 
@@ -9997,4 +9997,4 @@
  1,
  1,
  1,
- 1]
+ 2]

Ran 2 tests in 0.098s

FAILED (failures=2)
------------------------------------------------------------

rbtcollins · 2016-03-14T02:17:47Z

The new output seems ok to me?

elafontaine · 2017-02-07T23:26:36Z

Hi all,

What do we do with this ticket?

Patch were provided, People have agreed (I think). So what's missing to close it (or pass to the next step)? It's going to be a year that a high priority ticket has no update and I would like to accelerate it if I can :). Let me know what I can do.

Regards,
Eric Lafontaine

vstinner · 2017-02-08T08:36:46Z

unittest_unified_diff.patch: Rebased patch for the default branch. My patch updates also unit tests.

The patch changes the test output. If we decide to apply the patch, I propose to only apply it to the default branch (Python 3.7).

The bug report is about a test which fails. I'm not sure that it's a real blocker issue that Python is slow when a test fails. At least, it should be fast when a test pass. I mean that I like the current output, I'm not sure about the new output.

Example with attached unified_diff.py.

Before:
@@@@@@@@@@@@@@@@@
F
======================================================================
FAIL: test_x (main.Test)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "unified_diff.py", line 5, in test_x
    self.assertEqual([], [None])
AssertionError: Lists differ: [] != [None]

Second list contains 1 additional elements.
First extra element 0:
None

[]
+ [None]

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)
@@@@@@@@@@@@@@@@@

With the patch:
@@@@@@@@@@@@@@@@@
haypo@selma$ ./python unified_diff.py
F
======================================================================
FAIL: test_x (main.Test)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "unified_diff.py", line 5, in test_x
    self.assertEqual([], [None])
AssertionError: Lists differ: [] != [None]

Second list contains 1 additional elements.
First extra element 0:
None

--- 
+++ 
@@ -1 +1 @@
-[]
+[None]

Ran 1 test in 0.001s

FAILED (failures=1)
@@@@@@@@@@@@@@@@@

The patch adds the following header which can be suprising:
@@@@@@@@@@@@@@@@@

+++
@@ -1 +1 @@
@@@@@@@@@@@@@@@@@

Maybe we should pass a "file name" to unified_diff() to get something like:
@@@@@@@@@@@@@@@@@
--- expected
+++ got
@@ -1 +1 @@
@@@@@@@@@@@@@@@@@

eamanu · 2018-11-11T01:26:51Z

Hi!

I see that this issue have a pr (#10034) opened 20 days ago. So, I want to continue work on this (my first pr).

I use the vstinner's patch and I make two little change (attached patch):

first I add the "expected" and "got" mentioned by vstinner.
I quit the @@ -1 +1 @@ in case of the input are list or tuple, because IMO this does not give me lot of information (and could be confuse, because I can interpret that the lists differ on the first element)

This is the output for the vstinner test case.

What do you think?

eamanu · 2018-11-11T01:29:38Z

I create this patch on 3.7

treyhunner · 2020-06-02T21:44:58Z

This is a bug for string comparisons as well. I just had to manually reimplement assertMultiLineEqual (which doesn't call assertSequenceEqual) on one of my test classes to workaround this issue.

jdevries3133 · 2021-07-22T21:22:22Z

Hi all!

@eamanu, I went ahead and picked up where you left off. I stopped short of
opening up a PR, because I don't want to step on any toes, but I definitely
want to do what I can to give this bpo one final shove over the finish line.

Despite not creating a PR, you can see the changes here:

main...jdevries3133:bpo-19217-slow-assertEq

@eamanu, if you prefer, you can probably just merge this branch into
eamanu:fix_bpo-19217, and the conversation can move forward on #55413.

Also, below is a summary of what I've done:

Revert Change to difflib
========================

Link to the original thread where this change was discussed a bit:

#11204 (comment)

I assume this was a performance improvement. It's not clear to me why we are
not interested in this part of the diff when the input is a list or tuple.
I'm sure someone will help to explain, but this is why I reverted this change:

It is not an issue with unittest, and reaches beyond the scope of this bpo
The performance problem at the root of this bpo is solved without this
change.
Reverting this change fixes most of the cascading failures throughout other
parts of the test suite. It better constrains this fix to improving the
implementation's performance issues while limiting changes to behavior.

Obviously, I don't have knowledge of the reasoning behind this change
sufficient to write a new bpo, but I think that this small change does deserve
its own bpo with an independent explaination of what it does and why it should
be done.

It's definitely possible that I'm missing something here, so let me know if
that's the case!

Add Regression Test
===================

The regression test basically attempts to reproduce the problem and asserts
that the code will complete within one second. It's a pretty rough approach,
but I think that it will catch a future regression. If anyone has any better
ideas, I'm all ears.

Misc
====

I also fixed the one failing test in unittest's own test case, and added a
blurb.

terryjreedy · 2021-07-25T22:08:22Z

Lukasz, perhaps you can finish this. Too many assistent cooks and no chief cook. At least tell Jack (above) whether to submit his PR.

jdevries3133 · 2021-07-28T23:00:03Z

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 · 2021-11-07T01:55:06Z

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!

B703

JacekBzdak mannequin added stdlib Python modules in the Lib dir performance Performance or resource usage labels Oct 10, 2013

rhettinger assigned voidspace Oct 11, 2013

ezio-melotti assigned ezio-melotti and unassigned voidspace Oct 14, 2013

ezio-melotti added the easy label Apr 30, 2014

supriyantomaftuh mannequin added build The build process and cross-build docs Documentation in the Doc dir topic-unicode labels Apr 12, 2016

supriyantomaftuh mannequin added the topic-XML label Apr 12, 2016

berkerpeksag removed build The build process and cross-build docs Documentation in the Doc dir topic-unicode OS-windows topic-XML labels Apr 12, 2016

treyhunner added 3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes labels Jun 2, 2020

terryjreedy added 3.11 only security fixes and removed 3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes labels Jul 25, 2021

AlexWaygood removed the easy label Mar 4, 2022

ezio-melotti transferred this issue from another repository Apr 10, 2022

serhiy-storchaka added this to Unittest issues May 20, 2022

iritkatriel added 3.12 only security fixes and removed 3.11 only security fixes labels Sep 11, 2022

argilo mentioned this issue Oct 16, 2022

fec: Prevent integer overflow in path metric calculations gnuradio/gnuradio#6234

Merged

6 tasks

boaza mentioned this issue Nov 6, 2022

Calling unittest.assertDictEqual for medium-size dictionaries takes too long #99151

Open

bedevere-app bot mentioned this issue Apr 9, 2025

gh-63416: Speed up assertEqual on long sequences #27434

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Calling assertEquals for moderately long list takes too long #63416

Calling assertEquals for moderately long list takes too long #63416

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Calling assertEquals for moderately long list takes too long #63416

Calling assertEquals for moderately long list takes too long #63416

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

The patch adds the following header which can be suprising: @@@@@@@@@@@@@@@@@

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

The patch adds the following header which can be suprising:
@@@@@@@@@@@@@@@@@