Skip to content

RFC: impact of detectHostComponentNames #1579

Closed
@mdjastrzebski

Description

@mdjastrzebski

Summary

I've been curious what is the impact of automatically detecting host component names. Due to the lack of better large test suite I've taken RNTL own tests.

Here is my process:

  1. Disable tests that fail with hardcode hostComponentNames with test.skip().
  2. Measure execution time with time yarn test in relevant scenarios
  3. Add console.log() to detectHostComponentNames() and count execution count (separate run from measuring time).

Note: we also have beforeEach(() => resetToDefaults()), so I measured it with and without it.

  • Without detectHostComponentNames: 39,4 s / 0 runs
  • With detectHostComponentNames + without beforeEach(() => resetToDefaults()): 44,6 s / 63 runs => 13% overhead
  • With detectHostComponentNames + with beforeEach(() => resetToDefaults()): 47,1 s / 585 runs => 20% overhead

Seems like Jet by default clears the runtime state per each file. So we have detectHostComponentNames() being called for each file.

Here are my questions:

  • if if my methodology is correct?
  • did you observe the same/different effect on your own test-base? (here is a link previous perf impact issue of detect...)
  • is that number significant enough to warrant a research into alternative approaches?

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions