evanw / evanw/esbuild

Sanity Check: `separate entry points` faster than `combined entry points`?

Open
#4,261 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
40.1k
Forks
1.3k
PR merge metrics
No merged PRs in 30d

Description

"Multiple entry-points in one build context" should be faster than "single entry-points in many contexts"- since it only needs to crawl the file system once.

In my testing, the reverse has been the case (though only marginally)

Is esbuild doing something under the hood, are my tests flawed or is this a bug?

Update: I tried to account for parallel runs by limiting the cores available. `Combined Entry Points` wins in this case- which suggests that `separate entry points` had the same speed due to running two instances in parallel.

But I thought Esbuild used all the cores available? So for example, `combined entry with 8 cores` vs `separate entry x 2 with 4 cores each` would mean that combined should be x2 faster?

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the combined-entry-point and separate-entry-point comparisons described in the issue, including the constrained-core case. The report names no files, tests, or entry points, so locate the relevant build and parallelism code first. Done means establishing whether the timing difference is expected behavior or a bug, with a reproducible explanation.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
build-system, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.