Super slow HMR in meteor 3.0

3.0 migration
22

That might be too much telemetry on rebuild or at the very least, should not be blocking.

23

Were these requests only added in Meteor 3.0? The issue doesn’t seem to exist in 2.16.

24

I think It was there like decade ago but it run in background. Recently we move away from Fiber something changed.

1 Like
25

I can definitely reproduce the problem. I prepared the repository and compared the rebuild times between Meteor 2 and 3. I also tested by downgrading to 3.0.1 from 3.0.3 to identify any possible regression. But the issue is entirely happening on Meteor 3.0.

This issue lies in the core. There is an extra process that takes longer than expected or waits unnecessarily. We’ll need to debug the core using this app to identify it. We have noted the details and will investigate further.

6 Likes
26

Great to hear that you‘ll have a look at this, thanks.

That repo is from one of my students. I’ll let her know that her impatience while waiting for changes in her project contributed to solving this issue :wink:

5 Likes
27

By the way, is there a way to pick up the HMR state somehow to display sort of a loading indicator in dev mode in the browser?

28

That’s a good question, I just included a little debugging helper for my side which shows random emoji depending on the latest build time completion:

            // Let's fetch the current unique app version which should be changed for each HCP.
            // We'll always use the latest _cordova_ version info so we can compare the "emoji key"
            // between desktop and cordova versions when trying to figure out whether our cordova
            // version has the latest code. Most times both versions should change at the same time when
            // we edit the client code.
            const i = this.setInterval(() => {
                let versionHmr = Autoupdate._clientVersions?._versions?.get('web.cordova')?.versionHmr
                if (!versionHmr) return
                // We got the current version number now, it takes a bit after a refresh to arrive.
                // We use this to seed the random number generator and let it pick a few emoji to visualize the current
                // app "version".
                //
                // The nice thing is that it's a number already (last update timestamp I think)
                Srand.seed(versionHmr)
                const emojiArr = [...emojiString]
                console.log({emojiArr})
                const emoji = `` + Srand.choice(emojiArr) + Srand.choice(emojiArr) + Srand.choice(emojiArr)
                this.state.currentVersionEmojiKey = emoji
                clearInterval(i)
            }, 100)

This is incomplete, you need to provide it with a string of emojis like this: “:pancakes::unamused::weight_lifting_man::sun_behind_large_cloud:” or whatever you like (but put a few dozen in at least).

And you need to install the Srand package if you want the emoji :slight_smile:

But you can see where I pick up the latest build time here:

Autoupdate._clientVersions?._versions?.get('web.cordova')?.versionHmr

→ i’m not sure what of Autoupdate is reactive, if anything, but maybe it’s a good direction to poke at.

1 Like
29

@nachocodoner Is there already an issue on github associated to this?

30

No that I’m aware of.

Would you like to create one?

31

Ok, did that right here HMR Slowness with Meteor 3.0.3 + React + MUI6 · Issue #13430 · meteor/meteor · GitHub

4 Likes
32

I want to update that after some research, I believe I found the fix. I still need to verify it with the example app provided. I will do this next.

More details are available on the PR. Hopefully, we can include it in the next version.

3 Likes
33

Hi @nachocodoner, the beta of 3.1 has it fixed. I tested and in development changes are instantly reflected in the browser.

(also copying @leonardoventurini )

1 Like
34

I’d also like to try this, how can I use 3.1?

35

Strange, since these changes appeared after the 3.1 beta release. I can’t think of another change in the 3.1 beta that could have affected the build.

Alternatively, there might have been an issue with the record package usage, as @minhna reported, which was fixed automatically on the server status when you tested it. In my debugging, I didn’t notice any major changes in the package recording, but I did find other slowdowns in the build itself, which seem to be a negative impact and provided a fix already. I’ll review the recordPackageUsage to see if it’s affecting the rebuild flow under poor network conditions.

But definitely any of these changes would be available on the next beta or release.

36

Ok, I will update my largest project now and get back soon.

37

Ok, with this: Super slow HMR in meteor 3.0 - #8 by minhna, it takes less than a second (which I’d call instantly).

After removing that record from hosts, it takes between 1 and 3 seconds. I mean sometimes 1 sometimes 3

1 Like
38

Recording packages stats definitely caused slowdowns, included this fix as well as part of the set of changes for next release.

1 Like