Replies: 5 comments 26 replies
-
|
This issue really needs attention, and it is high priority. |
Beta Was this translation helpful? Give feedback.
-
|
I think they need to add timing data to the build process. You can't improve something if you don't measure. It will be interesting to see where the bottlenecks are. Are you using any of the new CSS features? |
Beta Was this translation helpful? Give feedback.
-
|
I removed some CSS plugins from esbuild, but it didn't have a significant impact on the performance. To assess the rebuild performance, I ran esbuild without remix, but it wasn't as efficient as some other build tools. Even a simple project with antd dependency takes 700ms to rebuild |
Beta Was this translation helpful? Give feedback.
-
|
is esbuild the bottlenecks? |
Beta Was this translation helpful? Give feedback.
-
|
I created a reproduce repo, if anyone want to try it. https://github.com/lili21/esbuild-rebuild-perf |
Beta Was this translation helpful? Give feedback.
-
|
Yea so in cases like this, we'd probably need to solve by doing pre-bundling for dependencies (fingerprinted by version) only once when that dependency is installed. There are trade-offs there (since treeshaking won't be as aggressive with pre-bundling), but that would make dev builds/rebuilds much faster in the presence of large dependencies. |
Beta Was this translation helpful? Give feedback.
-
|
The most helpful things for us to improve perf are reproductions that we can profile. So far in 1.16.1, 1.17.0, and 1.17.1, we've added some performance improvements. We already have fixes and improvements for 1.18 as well. If anyone can reproduce performance issues on latest Remix version (or better yet, on |
Beta Was this translation helpful? Give feedback.
-
|
I have a project and want to write the full stack with remix, but the packaging is getting slower and slower and I have to stop, this is not suitable, or I have to find another way to solve this problem, the project is in https://github.com/yyong008/remix-antd-admin |
Beta Was this translation helpful? Give feedback.
-
|
For compilation to scale well with app size (i.e. I tried out your repo locally on my M1 Max MBP (check out that sweet new log output 🤩): remix build
remix dev (
|
Beta Was this translation helpful? Give feedback.
-
|
Did a bit more digging and added perf profiling: 
Seems like CSS compilation accounts for 55% of your compilation time. ~2.7s with CSS, ~1.2s without CSS. Here's with all CSS features disabled): 
|
Beta Was this translation helpful? Give feedback.
-
|
You are also using |
Beta Was this translation helpful? Give feedback.
-
|
@pcattori, how could you enable the debug logs? |
Beta Was this translation helpful? Give feedback.
-
|
This is becoming unbearable in a medium sized project even in v2.0.1. Simple changes like amending a typo or adding a css class take 15 seconds to update on the browser. Is there anything that can be done to speed this up? It feels like the whole damn app is being rebuilt everytime a word changes. Its getting to the point where i've been looking at developing in storybook or a CRA app just so I can get anything done. Any hacky workarounds welcome
|
Beta Was this translation helpful? Give feedback.
-
|
I can have a look through all my installed libraries and see if there's anything obvious. I suspect In future is it feasable to add an --analyse parameter to 'npm run dev' or 'watch' to allow rebuild times to be analysed on a route/library basis to help pick out poor performers? (Sorry, genuine question, I have no idea at all how to approach such a task!) Edit: For reference, removing react-icons cut the rebuild time approximately by 50%. A huge improvement, but being able to easily analyse more gains would be so so useful! |
Beta Was this translation helpful? Give feedback.
-
|
Remix outputs metafiles alongside your server build (i.e. in the I'm already looking into how we can support more optimized dependency pre-bundling to skip rebuilding/rebundling dependencies during dev when those deps haven't changed. That should address the most common perf issues. |
Beta Was this translation helpful? Give feedback.
-
|
This could be exactly what everyone needs – the ability to develop and optimize for older, non-MacOS systems with M-series chips. |
Beta Was this translation helpful? Give feedback.
-
|
Definitely. I'm not even running on an old computer (razer book, about 2/3 years old) but it's still using intel architecture if that's a known slowdown. I've tried running in WSL with no visible gains. Using a macbook pro would be lovely but something that would be financially irresponsible for me to buy at this point. The solution of auditing and replacing libraries that don't tree shake well isn't a great solution either when running a production app with these libraries and features already live. What i'm comparing to is update speeds like Vite and CRA which happen almost instantly. I know the remix team have a focus on HMR for data consistency, but i'm spending 90% of my frontend dev time playing around with the creation of new components, html and CSS changes. Data consistency generally honestly doesn't bother me at all. I already do a full rebuild on every. single. update anyway so it wouldn't impact me to just restart when I expect data to change via updates to loaders etc. I guess what I'm saying is that it would be nice to allow 'remix dev' to be run in a mode with a gotcha that it doesn't gaurantee data consistency but allows for lightning quick HTML and tailwind changes. There are libraries that allow remix to be run using Vite but i've had problems with both of these and had to drop them. I also just want to add how awesome remix otherwise is and I really appreciate that this is a free tool run by volunteers. Howveer, this is perhaps the one single gripe I have with the framework, and it's a big deal. |
Beta Was this translation helpful? Give feedback.
-
|
We found out that there is a major issue specially with Windows systems (regardless of WSL or Native Windows environment). We experienced 10x speedup running the same project on Linux (Ubuntu) or Mac. |
Beta Was this translation helpful? Give feedback.
-
|
I have same issue with latest remix version. Every single change takes more than 1minute for me. I use Windows. |
Beta Was this translation helpful? Give feedback.
-
|
are you using vite? |
Beta Was this translation helpful? Give feedback.
-
|
This has become a major problem for us as well. We are a startup and have invested in the app enough that switching to next.Js would be next to impossible. This is urgent. Do we have any updates on this? For engineers and entrepreneurs considering remix, don't, for your sanity, until this is fixed. |
Beta Was this translation helpful? Give feedback.
-
|
did you try vite? |
Beta Was this translation helpful? Give feedback.
-
We did. To install the plug-in there was lots of work required to reach its requirements. It definitely helped. However we are moving away from Remix. |
Beta Was this translation helpful? Give feedback.
-
@Gsl-12 Performance with vite feels like magic to me, it drastically improved my experience. What is the reason for moving away even after trying vite? Just curious here... |
Beta Was this translation helpful? Give feedback.
-
Where are you going to? |
Beta Was this translation helpful? Give feedback.
-
React Router v7 |
Beta Was this translation helpful? Give feedback.
-
When working on a larger project, as the number of routes and components increases, along with the addition of third-party dependencies, the build time can increase to 20s+ or even longer. Making even a small change may require a rebuild of nearly 10+s. This significantly diminishes the development experience. Are there any solutions to this issue?
Beta Was this translation helpful? Give feedback.
All reactions