ameyms
Repos
34
Followers
52
Following
22

React component for animating numbers

165
25

A simple, elegant, fast & open source file explorer for Android

15
12

An opinionated starter kit for react with webpack & scss

An experimental router for browser side JS

A JQuery plugin for a commandline emulator with custom interpreters and formatter

Events

issue comment
Fix local demo

Realized this kinda breaks in the codesandbox demo too:

Screenshot 2022-12-30 at 8 54 42 PM

Created at 1 month ago
pull request opened
Fix local demo

I tried running the local demo and encountered several problems:

  • react-window was not defined
  • recoil was not defined

The other thing that slightly stumped me was all the scary eslint errors from mp4.js. Since I think its just copy-pasta, I have added it to .eslintignore for now. There was also a small warning about App.js having two default exports. So I fixed that as well.

Created at 1 month ago
create branch
ameyms create branch fix/fix-local-demo
Created at 1 month ago
Created at 1 month ago
issue comment
Use excalidraw for overlay

Does excalidraw (the repo) expose any primitives or libraries to handle drawing text/image etc? I think tldraw does. I could be wrong.

Created at 2 months ago

Fix typo in getting-started.mdx (#1785)

👋 This PR fixes a typo in the Getting Started docs.

Provide a bit more context for trace files. (#1768)

fix(docs): nextjs with-docker link (#1800)

Just a small fix.

Drop unused absolute unix path (#1791)

We don't use, and probably should not use, absolute unix paths. Unix paths are for sharing across machines, and absolute paths are for interacting with the local machine and should always be system paths.

Benchmarks: Install node_modules and reuse test directories (#284)

This:

  • Runs npm install in test directories to provide turbopack with modules necessary to bundle them.
  • Reuses test directories for iterations across the given benchmark. This prevents unnecessary file writing and npm install for each iteration, improving the times to run benchmarks.

Currently cherry-picks #278 as it's necessary along with #277.

Test Plan: Connected to the running devserver mid-test and confirmed no errors are thrown and the triangle is rendered correctly.

Benchmarks: assert that no runtime errors occur when loading pages (#285)

This adds an assertion that no runtime (browser) errors occurred when loading a benchmark page.

Test Plan: Temporarily removed the npm install for the test app and verified the benchmark failed as the test app requires react, react-dom. Restored the npm install and verified the benchmark runs to completion.

Generate .npmrc just-in-time (#1805)

Generate the .npmrc file before publishing, but don't check it into the repo

Co-authored-by: Nathan Hammond 20542+nathanhammond@users.noreply.github.com

fix: use docker cache best practices in examples (#1673)

The whole purpose of the turbo prune --docker is to use docker caching best practices while the Docker examples do not follow these bests practices.

Plus, I believe that the first stage of the Dockerfile is wrong as it copies the whole project and defeats the entire purpose of the caching because the first layer never gets cached. I believe the most optimized solution is to run the turbo prune before the docker build on the machine that runs the docker build and set the out directory as the docker build context.

I understand that showing this approach may not be possible in the example, so I suggest we add a comment to the first stage with the above explanation.

Postfix join and try_join (#300)

Instead of dropping back to prefix calling form in try_join_all(iterator_of_intofutures).await?, we now use postfix form iterator_of_intofutures.try_join().await?.

chore(deps): update dependency @babel/core to v7.18.13 (#1765)

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

dynamic imports for the test app, and fixes (#294)

add the ability to generate an test app with dynamic imports via option.

fixes chunking. It didn't handle async imports in the case where chunk where too large. The PR reuses the same logic for both cases now.

improve vizualization (#225)

chore(packages): typecheck and abstract ts config (#1807)

chore(ci): use remote cache for JS tests (#1808)

Set cmd.Dir to an absolute path when we execute scripts (#1774)

Setting cmd.Dir to an absolute path ensures that it will continue to work in the presence of the --cwd flag.

Bonus drop unused turboCache from execContext.

Note that this PR stacks on top of #1773

Remove errant indentation (#1810)

Fix syntax for github action so that it triggers properly

Remove --no-gc flag, always run with garbage collection (#1803)

This PR:

  • Removes the --no-gc flag
  • Makes using the GC the default.

A parsing bug meant no one was using --no-gc, so use this opportunity to enable GC. Benchmarks show negligible difference in execution time.

(refactor) add lockfile abstraction (#1789)

This PR introduces a new lockfile abstraction that will allow us to easily add more lockfile support to other package managers. It also

Notable changes:

  • Context now stores the lockfile interface instead of a yarn specific lockfile
  • PackageJson now only stores the package names as they appear in the lockfile, these will be mapped to their entries when the pruned lockfile is created
  • The initial implementation would cache the processed version of the yarn lockfile and attempt to use it. I did some light testing and I don't think this has a significant perf hit since the processing is straightforward.

From my understanding of Golang I think having Lockfile as an interface makes sense since each package manager has a different data layout for their lockfile e.g. pnpm has 6 top level entries and yarn's top level entries are the package entries themselves.

Testing: The e2e tests cover yarn prune, but I also tested that prune produces the an identical lockfile before and after these changes on a repo created with npx create-turbo.

Move fs.AbsolutePath to turbopath.AbsolutePath (#1779)

This PR does a few things:

  1. Moves fs.AbsolutePath to turbopath.AbsolutePath.
  2. (temporarily) Duplicates some utils and constants from fs into turbopath/absolute_path.go to prevent cycles. These will be removed in a followup commit.
  3. (in a separate commit) \b(fs\.)?AbsolutePath\b => turbopath.AbsolutePath. (excluding the turbopath folder)

The goal here is to make what are sweeping changes to the codebase still feel as incremental as possible. The next increment is turbopath.AbsolutePath to turbopath.AbsoluteSystemPath by combining the files and fixing the expectations of method calls throughout the codebase.

Use parking_lot in tt-memory (#288)

While profiling next-dev using cargo-instruments, I noticed that locking/unlocking the RwLock<TaskState> in turbo-tasks-memory was responsible for a significant chunk of the overall execution time.

My first reaction was to try to minimize the lifetime of the WriteGuard in add_to_scope_internal_shallow to avoid contention. However, it's unclear whether it's lock contention that's causing the slowdown, or if it's just the locking/unlocking mechanism of std::sync::RwLock itself. Instead, I switched to parking_lot::RwLock, and instantly noticed great improvements.

Benchmark: 30k sierpinski triangles

Before:

RUST_BACKTRACE=1 cargo run --bin next-dev --release -- triangles_30k --log-detail
   Compiling turbo-tasks-memory v0.1.0 (/Users/alex/dev/turbo-tooling/crates/turbo-tasks-memory)
   Compiling next-dev v0.1.0 (/Users/alex/dev/turbo-tooling/crates/next-dev)
    Finished release [optimized] target(s) in 9.40s
     Running `target/release/next-dev triangles_30k --log-detail`
server listening on: http://localhost:3000
start watcher /Users/alex/dev/turbo-tooling/triangles_30k/.next/server...
start watcher /Users/alex/dev/turbo-tooling/triangles_30k...
watching /Users/alex/dev/turbo-tooling/triangles_30k/.next/server...
watching /Users/alex/dev/turbo-tooling/triangles_30k...
initial compilation 23s (23s task execution, 2476451 tasks)
[TaskId 2476470] once took 1977ms
[TaskId 2476493] once took 2696ms
[TaskId 2476454] once took 3507ms
[TaskId 2476514] once took 5026ms
[TaskId 2917702] once took 2785ms
[TaskId 3083451] once took 1890ms
[TaskId 2917653] once took 4440ms
[TaskId 2994301] once took 1687ms
updated in 48s (1112024 tasks)

Total execution time 71s

image

After:

RUST_BACKTRACE=1 cargo run --bin next-dev --release -- triangles_30k --log-detail
    Finished release [optimized] target(s) in 0.57s
     Running `target/release/next-dev triangles_30k --log-detail`
server listening on: http://localhost:3000
start watcher /Users/alex/dev/turbo-tooling/triangles_30k...
start watcher /Users/alex/dev/turbo-tooling/triangles_30k/.next/server...
watching /Users/alex/dev/turbo-tooling/triangles_30k...
watching /Users/alex/dev/turbo-tooling/triangles_30k/.next/server...
initial compilation 5670ms (5602ms task execution, 2476451 tasks)
updated in 12s (1112024 tasks)
updated in 3.173ms (26 tasks)
updated in 2.579ms (48 tasks)
updated in 0.017ms (0 tasks)

Total execution time 18s

image

Task::add_to_scope_internal_shallow is still a very hot path, and three things stand out:

  • Allocating a Vec for children;
  • HashMap::entry;
  • The Mutex<TaskScopeState> in TaskScope: image

Replacing it with parking_lot::Mutex yields even greater improvements:

RUST_BACKTRACE=1 cargo run --bin next-dev --release -- triangles_30k --log-detail
   Compiling turbo-tasks-memory v0.1.0 (/Users/alex/dev/turbo-tooling/crates/turbo-tasks-memory)
   Compiling next-dev v0.1.0 (/Users/alex/dev/turbo-tooling/crates/next-dev)
    Finished release [optimized] target(s) in 7.12s
     Running `target/release/next-dev triangles_30k --log-detail`
server listening on: http://localhost:3000
start watcher /Users/alex/dev/turbo-tooling/triangles_30k...
start watcher /Users/alex/dev/turbo-tooling/triangles_30k/.next/server...
watching /Users/alex/dev/turbo-tooling/triangles_30k...
watching /Users/alex/dev/turbo-tooling/triangles_30k/.next/server...
initial compilation 5621ms (5513ms task execution, 2476451 tasks)
updated in 8128ms (1112023 tasks)

Total execution time 14s (5x speedup!)

image

Looking at the traces, it looks like there's more low-hanging fruits for further optimizing turbo-tasks and turbopack.

This was tested on macOS 12.5.1, Apple M1 Max, 32GB.

Traces: traces.zip

Created at 2 months ago