[fluffybucktsnek]

Other ECS implementations might not, but Bevy does come with a system scheduler. You register systems (functions that operate over the components) and, through their parameters, Bevy's scheduler decides how to parallelize the registered systems while avoid data races.

[CyberDildonics]

Other ECS implementations might not, but Bevy does come with a system scheduler.

That's an ecs data structure and a system scheduler. If I make a vector and a system scheduler, vectors don't suddenly have system schedulers, they are two different things.

You register systems (functions that operate over the components)

That's just adding a function pointer to a field.

[fluffybucktsnek]

> That's an ecs data structure [...]

ECS isn't a data structure tho, it's a pattern. You must be referring to the component storage. That's, at best, half the equation. You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?

> That's just adding a function pointer to field

Just as much as creating a new process, through the IP/PC field in the TCB. Don't know why you focused on that particular point, but sure.

[CyberDildonics]

ECS isn't a data structure tho, it's a pattern.

Every implementation out there is a data structure. You keep talking about things that use it and then lump them together. That's just you.

You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?

No, the first person I replied to said that justified a 50MB program. A few other software components don't make any sense either. 50MB is not something you get to with 4 or 5 parts of a game engine. That's the stripped binary too, it was originally 700MB.

Don't know why you focused on that particular point, but sure.

You brought it up, I'm not even sure what point you are trying to make.

[fluffybucktsnek]

> Every implementation out there is a data structure.

Examples?

> 50MB is not something you get to with 4 or 5 parts of a game engine.

Depends on the engine's architecture, runtime, etc. Again, don't know if you are blaming the bloat on those components alone (it seems like you are), but you haven't established a direct link between said components and the bloat, thus, it's hard to properly reason about the tradeoffs given that we don't know how said bloat scales.

> That's the stripped binary too, it was originally 700MB.

Actually, no. Rust doesn't strip binaries on release by default. There's a reason there's a guide about minimizing Rust program sizes.

> You brought it up, I'm not even sure what point you were trying to make.

You are the one who nitpicked over "You register functions", ignoring the rest of the sentence.

[CyberDildonics]

Depends on the engine's architecture,

No, it depends on excessive dependencies that themselves have dependencies.

There's a reason there's a guide about minimizing Rust program sizes.

And 50 MB was the stripped version, what is not sinking in?

[fluffybucktsnek]

> No, it depends on excessive dependencies that themselves have dependencies.

Not necessarily. Not every dependency will generate code. Furthermore, those dependencies of dependencies are rather small. If you're so certain that's the case, then provide an actual analysis over a case. Would be an interesting read.

> And that 50MB was the stripped version. What is not sinking in?

From the reddit post you linked:

> paholg: Rust debug binaries tend to be large. What's the size of you compile in release mode? > talentedBlue: 49M. looks more reasonable > CleanCut9: You can strip the release binary to get it even smaller if you want

What didn't sink in is the fact that you don't seem to have read the linked thread appropriately.