`import/namespace` is very slow

See original GitHub issue

In our medium-sized mixed JS/TS codebase, specifically disabling import/namespace significantly reduced our lint times. I haven’t found this mentioned by anyone else, so I wanted to share the finding, because it was very surprising.

Our prior configuration ran like this:

Rule                              | Time (ms) | Relative
:---------------------------------|----------:|--------:
import/namespace                  |  5762.140 |    64.7%
import/no-relative-packages       |   673.212 |     7.6%
import/named                      |   471.116 |     5.3%
import/no-extraneous-dependencies |   317.690 |     3.6%
import/extensions                 |   254.717 |     2.9%
Done in 14.53s.

I always assumed this was just the “first rule tax” while the export map is created, but adding "import/namespace": "off" did this for us:

Rule                              | Time (ms) | Relative
:---------------------------------|----------:|--------:
import/named                      |  1459.028 |    33.6%
import/no-relative-packages       |   577.911 |    13.3%
import/no-duplicates              |   408.152 |     9.4%
import/extensions                 |   401.591 |     9.2%
import/no-extraneous-dependencies |   276.880 |     6.4%
Done in 9.44s.

Given we already use "import/no-namespace": "error", this rule wasn’t doing anything for us anyway. With one line we’ve managed to significantly improve IDE responsiveness.

Issue Analytics

  • State:open
  • Created 2 years ago
  • Reactions:9
  • Comments:20 (10 by maintainers)

github_iconTop GitHub Comments

4reactions
ljharbcommented, Dec 29, 2021

Indeed, it’s not necessarily that that rule is slow - it’s that whichever rule is the first one to build up an ExportsMap of your entire codebase will be slow. Not every rule uses it.

However, named does use the ExportsMap, so something strange must be going on with the namespace rule. I’d be happy to review a PR that improved its performance.

2reactions
ljharbcommented, Apr 21, 2022

Yes, that’d be great. It especially must be set if you’re using “not standard javascript”, namely, TS.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Does including an entire namespace slow things down?
No matter what, including the entire namespace will not slow down production code. Will it slow down the compiler ...
Read more >
Very slow intellisense after import of large namespace — LINQPad
After adding a reference to Microsoft.Graph NuGet package and importing the Microsoft.Graph namespace intellisense becomes unbearably slow.
Read more >
The studio is very slow on a specific namespace
I'm trying to find solutions to a problem that's becoming quite boring. On only one namespace, the sudio is very slow. The studio...
Read more >
Import and export of a database takes a long time - Azure SQL ...
Azure SQL Database and Azure SQL Managed Instance Import/Export ... Exporting large tables without clustered indexes can be very slow or ...
Read more >
Programming FAQ — Python 3.11.1 documentation
Doing so clutters the importer's namespace, and makes it much harder for linters to detect undefined names. Import modules at the top of...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found