Use mimalloc in next-dev

[alexkirsz]

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

6 Ignored Deployments

Name	Status	Preview	Comments	Updated
examples-basic-web	⬜️ Ignored (Inspect)	Visit Preview		Nov 3, 2022 at 6:34AM (UTC)
examples-designsystem-docs	⬜️ Ignored (Inspect)	Visit Preview		Nov 3, 2022 at 6:34AM (UTC)
examples-kitchensink-blog	⬜️ Ignored (Inspect)	Visit Preview		Nov 3, 2022 at 6:34AM (UTC)
examples-native-web	⬜️ Ignored (Inspect)	Visit Preview		Nov 3, 2022 at 6:34AM (UTC)
examples-svelte-web	⬜️ Ignored (Inspect)	Visit Preview		Nov 3, 2022 at 6:34AM (UTC)
turbo-site	⬜️ Ignored (Inspect)	Visit Preview		Nov 3, 2022 at 6:34AM (UTC)

[jaredpalmer]

are we merging?

[kwonoj]

Just got build result from next-swc, good to go.

[Jerrody]

@alexkirsz What's the reason to use mimalloc instead of mimalloc_rust?

[alexkirsz]

@Jerrody mimalloc is the most well-maintained of the two.

[Jerrody]

@Jerrody mimalloc is the most well-maintained of the two.

How did you understand? Both of them are 1.7.6. Also, mimalloc_rust has an exposed mimalloc's API. I don't think that exists any reason for changing the crate.

[Jerrody]

@Jerrody mimalloc is the most well-maintained of the two.

This is the first thing, the second is what's the purpose of creating a TurboMalloc why don't use this:

static ALLOC: mimalloc_rust::GlobalMiMalloc = mimalloc_rust::GlobalMiMalloc;

It doesn't give any benefits from creating an additional type. At any rate, when you specify the global allocator all allocations in Rust will be handled from the specified global allocator.

In my opinion, this PR doesn't give any benefit, reason, or sense, but I'm not a maintainer.

[alexkirsz]

This is the first thing, the second is what's the purpose of creating a TurboMalloc why don't use this:

static ALLOC: mimalloc_rust::GlobalMiMalloc = mimalloc_rust::GlobalMiMalloc;

It doesn't give any benefits from creating an additional type. At any rate, when you specify the global allocator all allocations in Rust will be handled from the specified global allocator.

In my opinion, this PR doesn't give any benefit, reason, or sense, but I'm not a maintainer.

You still need to explicitly declare extern crate if you mean to use an allocator declared this way in another crate. I find the #[global_allocator] declaration clearer. In fact, we made this exact mistake before when depending on turbo-malloc and not declaring extern crate turbo_malloc. Which means that, at the moment, next-dev isn't using mimalloc at all.

[Jerrody]

You still need to explicitly declare extern crate if you mean to use an allocator declared this way in another crate. I find the #[global_allocator] declaration clearer. In fact, we made this exact mistake before when depending on turbo-malloc and not declaring extern crate turbo_malloc. Which means that, at the moment, next-dev isn't using mimalloc at all.

I still don't understand:

1. Why switch to mimalloc?
2. Why need to create an additional type TurboMalloc?

But you're right that need to declare a global allocator in the bin file.

You still need to explicitly declare extern crate if you mean to use an allocator declared this way in another crate. I find the #[global_allocator] declaration clearer.

About that, I didn't say anything against it. Everything is alright.

[alexkirsz]

I don't see a reference to mimalloc in Next.js so we might be good there.

[Brooooooklyn]

@alexkirsz next.js use mimalloc here https://github.com/vercel/next.js/blob/canary/packages/next-swc/crates/napi/src/lib.rs#L35

[sokra]

@alexkirsz next.js use mimalloc here https://github.com/vercel/next.js/blob/canary/packages/next-swc/crates/napi/src/lib.rs#L35

Can we use the same method for our code?

[alexkirsz]

@sokra This is what we were doing previously for NFT. We can do this here too, I just thought the #[global_allocator] way is cleaner (no implicit behavior).

[sokra]

We can do this here too, I just thought the #[global_allocator] way is cleaner (no implicit behavior).

I'm fine with any of these ways, but I'm all for consistency. It should be the same way in next-swc and in this repo. I don't want to introduce random differences between tested version and published version.

[Jerrody]

You still need to explicitly declare extern crate if you mean to use an allocator declared this way in another crate. I find the #[global_allocator] declaration clearer. In fact, we made this exact mistake before when depending on turbo-malloc and not declaring extern crate turbo_malloc. Which means that, at the moment, next-dev isn't using mimalloc at all.

I still don't understand:

1. Why switch to mimalloc?
2. Why need to create an additional type TurboMalloc?

But you're right that need to declare a global allocator in the bin file.

You still need to explicitly declare extern crate if you mean to use an allocator declared this way in another crate. I find the #[global_allocator] declaration clearer.

About that, I didn't say anything against it. Everything is alright.

No answer. As I said I don't see any reason for:

• Switch to mimalloc.
• Create an additional type TurboMalloc that doesn't give any benefit in comparison with just using:

#[global_allocator]
static ALLOC: mimalloc_rust::GlobalMiMalloc = mimalloc_rust::GlobalMiMalloc;