Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential optimizations to improve the plugin's speed significantly #55

Open
notcome opened this issue Mar 5, 2025 · 1 comment
Open

Comments

@notcome
Copy link

notcome commented Mar 5, 2025

I have made a proof-of-concept plugin that brings a 10x speedup in my mini-sized monorepo + react router setup, from 50s ish to 5s ish in initial dev build, and slashes my production build time by half.

The following optimizations are possible:

  1. When we call deno info --json, we get not only that particular file's location, but also all of its imports'. The current code partially uses that info to resolve a relative import path to the absolute path within that module, but nonetheless calls deno info just to obtain the file location.

  2. There are some temporary paths from vite that will not resolve to anything, but we still perform deno info for them. I am not familiar with vite or front-end bundling in general, but in my code base, I have found at least the following:

    • /__manifest?
    • /@id/__x00
    • /shadcn/

    The last one is project-specific. Still, it is nice to allow users of this plugin to enter a list of prefixes to do a fast failure.

  3. Vite currently runs resolveId in parallel. Therefore, to make caching utilized, we need a lock around deno info and all the post-processing from step 1.

  4. Right now, I am using the final resolved file path as the absolute unique ID for a file, just as your original code. However, I think for local packages within a workspace, we shall be able to cache them also by their package names. Furthermore, we might not need to call deno info for them, as we can parse deno.json for each local package manually.

  5. Maybe we can cache those results in a local SQLite file to further improve the performance.

I am very new to Deno and honestly not very familiar with Vite either. Therefore, I am not very confident about my optimization steps outlined above -- though it does work for my build and brings much joy to the developer experience. I am willing to start a pull request to improve the package, but I would like to have a discussion on these matters, to make sure my understanding of the whole thing is correct.

@marvinhagemeister
Copy link
Collaborator

Go for it, these are all valid optimization strategies 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants