The default bug view has changed. See this FAQ.

Speed up test_value_cloning.html

RESOLVED FIXED in mozilla7

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

Trunk
mozilla7
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Patch coming up that makes this test take 7s in a debug build on my machine instead of 170s.
Summary: Speed up test_value_storage.html → Speed up test_value_cloning.html
Created attachment 535795 [details] [diff] [review]
Speed up test_value_cloning.   fundamental change is that instead of using 3000+ separate documents to test this we use one big document with distinct IDs for all the tests.
Attachment #535795 - Flags: review?(dbaron)
Comment on attachment 535795 [details] [diff] [review]
Speed up test_value_cloning.   fundamental change is that instead of using 3000+ separate documents to test this we use one big document with distinct IDs for all the tests.

There are fewer cases to test than there used to be... but could you
test that if you break cloning of some value types (say, by removing the
eCSSUnit_Gradient in nsCSSValue::nsCSSValue) that the relevant tests in
test_value_cloning still fail?

test_value_storage:

  Change serialize_comparatar to serialize_comparator or maybe just to
  serialize_func.  And perhaps where you use it, don't reindent the
  later lines (that's the existing style I've used in such cases, since
  it's temporary).

  And where you change the assignment to |func|, could you write (a ||
  b) ? c : d so I don't have to think about operator precedence?

test_value_cloning:

  Remove the SimpleTest.requestLongerTimeout(4).

r=dbaron with that

Thanks for doing this.  I should have done something like this the first time around.
Attachment #535795 - Flags: review?(dbaron) → review+
> say, by removing the eCSSUnit_Gradient in nsCSSValue::nsCSSValue

That codepath is not hit by this test....  Looking into that.
Ah, it's not hit because we only do gradients in background-image and that's a list, so cloning just refcounts the list.

I hacked the "cloning a float value" case to add 0.001 and lots of tests fail as a result, as expected.
> Change serialize_comparatar to serialize_comparator or maybe just to
> serialize_func.

Oops, a typo and then autocomplete... Changed to serialize_func and undid the indent.

> could you write (a || b) ? c : d

Yes.

>  Remove the SimpleTest.requestLongerTimeout(4).

Done.

Pushed http://hg.mozilla.org/projects/cedar/rev/d0423bbf0391
Flags: in-testsuite-
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: fixed-in-cedar
Target Milestone: --- → mozilla7
Pushed:
http://hg.mozilla.org/mozilla-central/rev/d0423bbf0391
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: fixed-in-cedar
This test is causing the mochitest run to fail if I run all the layout/style/tests tests, because Fennec is closing during this test. I think it's happening, because this test is using a lot of memory and my phone only has 512MB ram.

Perhaps this test should be broken up in smaller chunks? Or perhaps I should buy more ram?
This test used to be broken up into smaller chunks... that caused it to take forever to run.

That said, 512 megs is a lot more than I recall this test taking when I tested it.  If it's really hitting that much RAM, maybe we should try splitting things up into 2-3 chunks somehow....  Can you file a bug on that, please?
That's probably bug 704010, now.
You need to log in before you can comment on or make changes to this bug.