It's a single data structure that contains your entire game though?
Are you asking?
but calling it a "single data structure" is a bit reductive.
No it isn't. It's like a tiny database. Depending on how someone implements it, it could use arrays, hash maps and b-trees. There is no universe where this means a binary that does nothing should be 50 megabytes.
I would say yes it’s like a tiny database but as well as all the other things your added. And I think that’s a good thing, because it does this at the type level!
I’m actually seeing if I can build a parser using bevy_ecs just because the way their state machine works, it looks like it would be fun
In this case systems are the S of ECS and contain all your game logic, acting upon the entities and components (E and C).
By system management I assume they mean the APIs bevy offers for scheduling and sequencing systems and events so your game logic remains modularized while still running in the correct order.
It seems like you're calling an entire game engine "ECS". I'm not sure what the point is here, the whole question was what justifies having a 50 MB hello world binary. It doesn't matter what you put into a data structure, the data structure itself shouldn't make 50 MB binaries.
No, they aren't calling the entire game engine "ECS". Entity-Component-System is an architecture that Bevy is structured around.
As I have previously stated, I wouldn't blame the data structures used behind Bevy just yet, given Rust's tendency for making bloated binaries. What is taking the most space in this 50MB binary? How does it scale with the complexity of the application?
I don't know where you are trying to go with this logic. You still haven't assured that the 50MB is actually related to data structures used behind by bevy, lest you are insunating that the data structures used by bevy are solely responsible for that size, which is not what the post claims.
How small is a hello world in C on Linux? The last time I checked a few years ago, it was either 9Mb or 13Mb (memory is fuzzy on this one but one of them was right).
Edit: wow I’m way off… it must have been the 90s when I checked this lol
Yeah, testing here with GCC 13.3.0 led to 16K. Perhaps, when you made your test, the compiler was statically linking some libs, which would explain the massive increase in size.
I know the thread. Your point is about whether Bevy's "data structure" is worth 50MB. I pressing on the fact that you haven't shown what this 50MB actually are.
But, out of curiosity, do you also consider the Linux Kernel also a data structure?
To be clear you think an ECS implementation is 50MB?
No.
Do you think a spreadsheet the[sic] holds a function pointer is a kernel?
Do you think an entire engine, including its system scheduler, is a spreadsheet? If so, shouldn't be hard to apply the same argument to any kernel. Of course, it all relies on your definitions and sense of reductionism.
I think you're conflating other big features of a game engine with a way to store data. If you look at other ecs implementations they are data structures, they don't do "system scheduling" (is that different from regular scheduling?)
First of, Bevy isn't just an ECS implementation. It's a game engine designed around ECS. While the ECS part is its core, Bevy also provides rendering, resource management, physics, etc. One of its other tasks, a rather important one too, is system scheduling: once you register systems, Bevy is responsible for dispatching them each frame, at the appropriate time, while also avoid data races over global resources and components.
No one thought that or said that so I don't know what point you're trying to make.
If you go to the comments I replied it was someone saying bevy compiles slow and has excessive bloated binaries. Someone else replied that you get so much, like ecs. Then I said that ecs specifically is just a data structure and has no reason to bloat binaries to be 50MB for an empty program that does nothing.
You're replying about things no one was discussing.
Your whole thread is about nitpicking the phrase "Bevy gives you a nice ECS". You are the one who asserted that "ecs specifically is just a data structure" (it isn't, by most definitions [1] [2], except yours). I supposed you were referring exclusively to a simple and basic component storage implementation (which is a data storage), where as OP was probably referring to the whole ergonomics of writing programs in it, alongside all the other features. It seems to me that you're the one who missed the point.
Then, you used this reductionism to question whether the 50MB binary is worth it. And that's ignoring the fact that there are ways to cut it if you wish, as mentioned in the reddit thread. And then there's the issue of whether it will actually matter for a full game.
I will need citation on which link, and how it defines ECS as a data structure.
From [1]:
Entity component system (ECS) is a software architectural pattern. An ECS consists of entities composed of data components, along with systems that operate on those components.
From [2]:
> ECS ("Entity Component System") describes a design approach which promotes code reusability by separating data from behavior. Data is often stored in cache-friendly ways which benefits performance.
What you just described is a data structure that gets used. If the user brings the behavior what is the ecs? It's the data structure.
Of course it will be used somehow. I don't call a std::vector a "vector system" because someone uses it, but I guess people think using this data structure makes it a "system".
It's a data structure, except it doesn't describe how data is actually stored, only how its elements interact, so it's a data structure that doesn't actually structure data. If you are the kind of person that considers stuff like MVVM and Clean Architecture to be data structures, then I suppose it would be consistent. Most people don't.
It does store data so it is a data structure. Every implementation is meant to store data and the whole point is to have more memory locality so how it stores data is actually crucial.
No, not every ECS implementation is about data storage (to be more precise, component storage). This architecture's abstraction being better suited for data locality is the main appeal, yes, but many appreciate the mere separation of the GameComponent's Components into Components and Systems. So your assertion about it being strictly meant for data storage is just wrong. As [2] states:
Data is often stored in cache-friendly ways which benefits performance.
Notice it says often, not always.
And bear in mind, generally, data structures aren't just about storing data. They are about storing data in a very particular way.
That's data, so it stores data, so it's data structure.
Technically, the component storage is, at best, a ADS. But that's grasping at straws given that you can just store components directly in a function's stack frame. Still, the component storage isn't "the ECS" in the same way that a service injector isn't "the Clean Architecture ", even though you'll always have them in some form in each.
No, using data structure doesn't mean it isn't one.
Now, where did I say that?
This doesn't matter.
For the discussion of whether ECS is a data structure, it is, given that you previously stated that ECS was meant for storing data, and "often" contradicts that.
You're way off the map in what causes 50MB binaries.
I haven't asserted anything about it. You did, and you have yet to prove it.
Same thing
Pretty much everything stores data in someway. Which brings us back to the "kernel is a data structure in your eyes?" question from earlier. I don't think it is me who isn't making much of a point.
No one knows or cares about whatever "ADS" is, injector services or 'clean architecture'. It seems like you're caught up in so much nonsense that you don't think that a class meant to store data is a data structure.
Funny, there are no classes named "ECS" in that link. In fact, there are no classes at all, because you didn't actually link a class source. Why push the step of searching for the class towards the reader when you could do it yourself? Wasn't it easy? I wonder why?
Taking a cursory look (which is already beyond my responsibilities) at https://github.com/redxdev/ECS/blob/master/ECS.h, by searching "class ECS" and "struct ECS" and "EntityComponentSystem" wields no results.
They're ecs, some of them are wrapped in classes. Classes are just a simple programming structure. You should probably learn how to program before arguing all this stuff.
You should probably learn how to program before arguing all this stuff.
Notice how I didn't reveal whether I program or not, yet you still made assumptions about it. I suspect that you either are a poor programmer or a troll.
Didn't you just say something about "ad hominem" (even though you used it incorrectly, pointing out something negative if it's related is not ad hominem).
You don't know what a data structure is or what a class does or doesn't do, that's not something programmers have to worry about. They don't have to consult wikipedia for a definition.
It would be ad hominen argument if it was an argument, not a side note. Whereas, in your case, you used to dismiss my position as "no real programmer needs to consult the Wikipedia for definitions" (according to whom, you?).
Since you failed to cite any third party source for definitions, whether your definitions are actually conventional depend solely on your authority as a programmer, in contrast to me, who cited Wikipedia (and there are many others I can cite too). An attack on your authority is no longer a fallacy, but, towards me, it is, since I never relied on my authority as a programmer.
Never mind the fact that being a good programmer doesn't mean you know the definition of technical terms.
Your link was basically a gish-gallop. I explicitly asked to asked link an "ECS" class source, instead you link an index of ECS libraries/engines/frameworks (not data structures, mind you). I picked the first, showed there was no "ECS" class, and your retort was "Theyre ecs". Now, your only retort is basically "all programmers now this". Can't speak for all programmers, but if someone were to ask for a array list implementation, I can easily directly link to Rust's Vec, or C++'s std::vector, or Java's ArrayList. Why can't you do the same for ECS if: a) it's also a class; b) it's easy to find?
Yes it does. How would you know?
Better question: why being a good programmer guarantees you good knowledge about technical definitions? Being a good mason doesn't mean you have the formal knowledge of a civil engineer.
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.
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)
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.
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.
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.
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.
Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint.
Which brings to...
No, they add up to 50MB.
You are just asserting this. The thread you linked doesn't really support this. So I'm asking for actual proof, like a disassembly, or analysis through other tooling.
Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint.
That makes zero sense. That's like saying your luggage can't be too heavy because it contains a feather. Think about this super hard.
So I'm asking for actual proof, like a disassembly, or analysis through other tooling.
That's like saying your luggage can't be too heavy because it contains a feather. Think about it super hard.
There's nothing to think here. This analogy is stupid at best, profoundly ignorant at worst. We both agree that the binary is 50MB (the weight), so the "luggage can't be too heavy" is already nonsense.
You think you need disassembly to see file sizes?
I mean the cause for the 50MB, if that wasn't clear (somehow).
This analogy is stupid at best, profoundly ignorant at worst.
No it isn't. If you could explain why you would have already. Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make any sense. Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50 MB of stuff to do what they need.
I have my suspicions. But I rather speak with certainty rather than spout unfounded hypotheses as facts.
Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make sense.
If I did say that. I said that isn't necessarily dependencies, because you have yet to prove it. If you do prove it, then that is that. As of now, all you've shown is that thread.
Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50MB of stuff to do what they need.
Restating what I've said prior, you are just asserting this, but have yet to prove it. For starters, what are the specific bloated dependencies? How much space does each dependency actually occupy in the final binary? A disassembly would answer those really quickly.
Even though you have to actually substantantiate this, for the sake of brevity, let's go with it. All you have crossed is a single potential cause, not proven a particular one.
Have you ever programmed before?
Let's say I haven't. How would it impact your argument? Whether I'm a programmer or not won't magically substantiate your position.
That explains why what you're saying and focusing on doesn't seem to make sense.
Or it could be just you. Even presuming you're a good programmer, that wouldn't make your arguments good by default.
Data structures are parts of the program that hold data.
Not according to Wikipedia:
In computer science, a data structure is a data organization and storage format that is usually chosen for efficient access to data.
ECS doesn't stipulate any storage format, as shown by the previous definitions, only that your application will be architected around Entities, Components and Systems. How they are stored/managed is up to the programs/frameworks/engines to decide, and this storage is just one concern an implementation may have, just like how storing ViewModels is just one concern of a MVVM framework, but not all.
I'm no stranger to using unorthodox definitions, but I would prefer if you were upfront that your definitions are unconventional, rather than pretend that they are common sense without citing any third party authority.
You don't realize wikipedia is saying the same thing and you don't realize what 'format' or 'structure' means or that some terms aren't specific. Please learn how to program before talking about programming.
So, rather than actually explain what Wikipedia means with terms such as "data organization" and "storage format", you just dismiss the whole thing with an ad hominem.
From HN guidelines:
Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
Comments
It's a single data structure that contains your entire game though?
Are you asking?
but calling it a "single data structure" is a bit reductive.
No it isn't. It's like a tiny database. Depending on how someone implements it, it could use arrays, hash maps and b-trees. There is no universe where this means a binary that does nothing should be 50 megabytes.
No it isn't. It also handles system management and concurrency, basically the main loop of your application.
I also would be cautious of assigning the blame of the binary size onto the data structure on its own.
I would say yes it’s like a tiny database but as well as all the other things your added. And I think that’s a good thing, because it does this at the type level!
I’m actually seeing if I can build a parser using bevy_ecs just because the way their state machine works, it looks like it would be fun
system management
What does that mean?
concurrency
Some data structures and databases deal with concurrency.
In this case systems are the S of ECS and contain all your game logic, acting upon the entities and components (E and C).
By system management I assume they mean the APIs bevy offers for scheduling and sequencing systems and events so your game logic remains modularized while still running in the correct order.
It seems like you're calling an entire game engine "ECS". I'm not sure what the point is here, the whole question was what justifies having a 50 MB hello world binary. It doesn't matter what you put into a data structure, the data structure itself shouldn't make 50 MB binaries.
No, they aren't calling the entire game engine "ECS". Entity-Component-System is an architecture that Bevy is structured around.
As I have previously stated, I wouldn't blame the data structures used behind Bevy just yet, given Rust's tendency for making bloated binaries. What is taking the most space in this 50MB binary? How does it scale with the complexity of the application?
Even if you can put a function pointer into a data structure, that's still just a data structure.
I don't know where you are trying to go with this logic. You still haven't assured that the 50MB is actually related to data structures used behind by bevy, lest you are insunating that the data structures used by bevy are solely responsible for that size, which is not what the post claims.
How small is a hello world in C on Linux? The last time I checked a few years ago, it was either 9Mb or 13Mb (memory is fuzzy on this one but one of them was right).
Edit: wow I’m way off… it must have been the 90s when I checked this lol
C statically linked hello world binaries have never been 9MB or 13MB, they definitely weren't in the 90s. Also these are rust binaries.
https://github.com/MichalStrehovsky/sizegame
Yeah, testing here with GCC 13.3.0 led to 16K. Perhaps, when you made your test, the compiler was statically linking some libs, which would explain the massive increase in size.
You should probably read the whole thread. You jumped in half way through and got all mixed up.
I know the thread. Your point is about whether Bevy's "data structure" is worth 50MB. I pressing on the fact that you haven't shown what this 50MB actually are.
But, out of curiosity, do you also consider the Linux Kernel also a data structure?
I pressing on the fact that you haven't shown what this 50MB actually are.
To be clear you think an ECS implementation is 50 MB?
But, out of curiosity, do you also consider the Linux Kernel also a data structure?
Do you think a spreadsheet the holds function pointers is a kernel?
No.
Do you think an entire engine, including its system scheduler, is a spreadsheet? If so, shouldn't be hard to apply the same argument to any kernel. Of course, it all relies on your definitions and sense of reductionism.
I think you're conflating other big features of a game engine with a way to store data. If you look at other ecs implementations they are data structures, they don't do "system scheduling" (is that different from regular scheduling?)
First of, Bevy isn't just an ECS implementation. It's a game engine designed around ECS. While the ECS part is its core, Bevy also provides rendering, resource management, physics, etc. One of its other tasks, a rather important one too, is system scheduling: once you register systems, Bevy is responsible for dispatching them each frame, at the appropriate time, while also avoid data races over global resources and components.
First of, Bevy isn't just an ECS implementation.
No one thought that or said that so I don't know what point you're trying to make.
If you go to the comments I replied it was someone saying bevy compiles slow and has excessive bloated binaries. Someone else replied that you get so much, like ecs. Then I said that ecs specifically is just a data structure and has no reason to bloat binaries to be 50MB for an empty program that does nothing.
You're replying about things no one was discussing.
Your whole thread is about nitpicking the phrase "Bevy gives you a nice ECS". You are the one who asserted that "ecs specifically is just a data structure" (it isn't, by most definitions [1] [2], except yours). I supposed you were referring exclusively to a simple and basic component storage implementation (which is a data storage), where as OP was probably referring to the whole ergonomics of writing programs in it, alongside all the other features. It seems to me that you're the one who missed the point.
Then, you used this reductionism to question whether the 50MB binary is worth it. And that's ignoring the fact that there are ways to cut it if you wish, as mentioned in the reddit thread. And then there's the issue of whether it will actually matter for a full game.
[1] https://en.wikipedia.org/wiki/Entity_component_system
[2] https://github.com/SanderMertens/ecs-faq#what-is-ecs
Your link describes a data structure and then just says "systems that use it" which is implied. Of course it gets used. Seems tautological.
I will need citation on which link, and how it defines ECS as a data structure.
From [1]:
From [2]: > ECS ("Entity Component System") describes a design approach which promotes code reusability by separating data from behavior. Data is often stored in cache-friendly ways which benefits performance.
What you just described is a data structure that gets used. If the user brings the behavior what is the ecs? It's the data structure.
Of course it will be used somehow. I don't call a std::vector a "vector system" because someone uses it, but I guess people think using this data structure makes it a "system".
It's a data structure, except it doesn't describe how data is actually stored, only how its elements interact, so it's a data structure that doesn't actually structure data. If you are the kind of person that considers stuff like MVVM and Clean Architecture to be data structures, then I suppose it would be consistent. Most people don't.
It does store data so it is a data structure. Every implementation is meant to store data and the whole point is to have more memory locality so how it stores data is actually crucial.
No, not every ECS implementation is about data storage (to be more precise, component storage). This architecture's abstraction being better suited for data locality is the main appeal, yes, but many appreciate the mere separation of the GameComponent's Components into Components and Systems. So your assertion about it being strictly meant for data storage is just wrong. As [2] states:
Notice it says often, not always.
And bear in mind, generally, data structures aren't just about storing data. They are about storing data in a very particular way.
(to be more precise, component storage)
That's data, so it stores data, meaning it is a data structure.
So your assertion about it being strictly meant for data storage is just wrong.
No, using a data structure doesn't mean it isn't one.
Notice it says often, not always.
This doesn't matter. You're way off the map in what causes 50MB binaries.
data structures aren't just about storing data. They are about storing data in a very particular way.
Same thing, you're pretty deep in the replies and still not making a point.
Technically, the component storage is, at best, a ADS. But that's grasping at straws given that you can just store components directly in a function's stack frame. Still, the component storage isn't "the ECS" in the same way that a service injector isn't "the Clean Architecture ", even though you'll always have them in some form in each.
Now, where did I say that?
For the discussion of whether ECS is a data structure, it is, given that you previously stated that ECS was meant for storing data, and "often" contradicts that.
I haven't asserted anything about it. You did, and you have yet to prove it.
Pretty much everything stores data in someway. Which brings us back to the "kernel is a data structure in your eyes?" question from earlier. I don't think it is me who isn't making much of a point.
No one knows or cares about whatever "ADS" is, injector services or 'clean architecture'. It seems like you're caught up in so much nonsense that you don't think that a class meant to store data is a data structure.
ADS stands for Abstract Data Structure. ECS ain't even a class. Nothing you're saying now is making sense.
Edit: checking now ADS is a too literal of a translation (English isn't my first language). The more appropriate term is ADT.
ECS ain't even a class.
ECS is an abstract term for a data structure. Have you ever programmed before?
Sources? I have cited mine for why it isn't.
You want a source for saying an ecs can be implemented as a class? It's all over github.
Then, surely, you should be able to find a link to a ECS class's source easily. So where is it?
Also, remember, it's not my responsibility to search to prove your arguments. Burden of proof is on the claimant, as it goes.
https://jslee02.github.io/awesome-entity-component-system/
Funny, there are no classes named "ECS" in that link. In fact, there are no classes at all, because you didn't actually link a class source. Why push the step of searching for the class towards the reader when you could do it yourself? Wasn't it easy? I wonder why?
Taking a cursory look (which is already beyond my responsibilities) at https://github.com/redxdev/ECS/blob/master/ECS.h, by searching "class ECS" and "struct ECS" and "EntityComponentSystem" wields no results.
They're ecs, some of them are wrapped in classes. Classes are just a simple programming structure. You should probably learn how to program before arguing all this stuff.
No, they aren't.
Notice how I didn't reveal whether I program or not, yet you still made assumptions about it. I suspect that you either are a poor programmer or a troll.
you either are a poor programmer or a troll.
Didn't you just say something about "ad hominem" (even though you used it incorrectly, pointing out something negative if it's related is not ad hominem).
You don't know what a data structure is or what a class does or doesn't do, that's not something programmers have to worry about. They don't have to consult wikipedia for a definition.
It would be ad hominen argument if it was an argument, not a side note. Whereas, in your case, you used to dismiss my position as "no real programmer needs to consult the Wikipedia for definitions" (according to whom, you?).
Since you failed to cite any third party source for definitions, whether your definitions are actually conventional depend solely on your authority as a programmer, in contrast to me, who cited Wikipedia (and there are many others I can cite too). An attack on your authority is no longer a fallacy, but, towards me, it is, since I never relied on my authority as a programmer.
Never mind the fact that being a good programmer doesn't mean you know the definition of technical terms.
I linked you hundred different ecs data structures, did you ever learn how to program?
Never mind the fact that being a good programmer doesn't mean you know the definition of technical terms.
Yes it does. How would you know?
Your link was basically a gish-gallop. I explicitly asked to asked link an "ECS" class source, instead you link an index of ECS libraries/engines/frameworks (not data structures, mind you). I picked the first, showed there was no "ECS" class, and your retort was "Theyre ecs". Now, your only retort is basically "all programmers now this". Can't speak for all programmers, but if someone were to ask for a array list implementation, I can easily directly link to Rust's Vec, or C++'s std::vector, or Java's ArrayList. Why can't you do the same for ECS if: a) it's also a class; b) it's easy to find?
Better question: why being a good programmer guarantees you good knowledge about technical definitions? Being a good mason doesn't mean you have the formal knowledge of a civil engineer.
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.
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.
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?
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.
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.
Examples?
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.
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 are the one who nitpicked over "You register functions", ignoring the rest of the sentence.
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?
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.
From the reddit post you linked:
What didn't sink in is the fact that you don't seem to have read the linked thread appropriately.
Not every dependency will generate code.
Who said that?
Furthermore, those dependencies of dependencies are rather small.
No, they add up to 50 MB.
Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint.
Which brings to...
You are just asserting this. The thread you linked doesn't really support this. So I'm asking for actual proof, like a disassembly, or analysis through other tooling.
Your assertion that dependencies are the cause of the bloat is only trivially acceptable if, at least, every dependency actually contributed into the binary size, nevertheless in a significant manner. Thus it is a counterpoint.
That makes zero sense. That's like saying your luggage can't be too heavy because it contains a feather. Think about this super hard.
So I'm asking for actual proof, like a disassembly, or analysis through other tooling.
You think you need disassembly to see file sizes?
There's nothing to think here. This analogy is stupid at best, profoundly ignorant at worst. We both agree that the binary is 50MB (the weight), so the "luggage can't be too heavy" is already nonsense.
I mean the cause for the 50MB, if that wasn't clear (somehow).
This analogy is stupid at best, profoundly ignorant at worst.
No it isn't. If you could explain why you would have already. Saying that some dependencies aren't heavy so the problem isn't dependencies doesn't make any sense. Huge bloated binaries are from lots of bloated dependencies because people aren't actually writing 50 MB of stuff to do what they need.
I have my suspicions. But I rather speak with certainty rather than spout unfounded hypotheses as facts.
If I did say that. I said that isn't necessarily dependencies, because you have yet to prove it. If you do prove it, then that is that. As of now, all you've shown is that thread.
Restating what I've said prior, you are just asserting this, but have yet to prove it. For starters, what are the specific bloated dependencies? How much space does each dependency actually occupy in the final binary? A disassembly would answer those really quickly.
what are the specific bloated dependencies?
Not a single data structure, that's for sure. Have you ever programmed before?
Even though you have to actually substantantiate this, for the sake of brevity, let's go with it. All you have crossed is a single potential cause, not proven a particular one.
Let's say I haven't. How would it impact your argument? Whether I'm a programmer or not won't magically substantiate your position.
Let's say I haven't.
That explains why what you're saying and focusing on doesn't seem to really make sense.
Even though you have to actually substantantiate this,
Data structures are parts of programs that hold data. Have you made a data structure before?
Or it could be just you. Even presuming you're a good programmer, that wouldn't make your arguments good by default.
Not according to Wikipedia:
ECS doesn't stipulate any storage format, as shown by the previous definitions, only that your application will be architected around Entities, Components and Systems. How they are stored/managed is up to the programs/frameworks/engines to decide, and this storage is just one concern an implementation may have, just like how storing ViewModels is just one concern of a MVVM framework, but not all.
I'm no stranger to using unorthodox definitions, but I would prefer if you were upfront that your definitions are unconventional, rather than pretend that they are common sense without citing any third party authority.
So programming doesn't matter and data structures don't hold data?
Please cite exactly where I said any of that.
You don't realize wikipedia is saying the same thing and you don't realize what 'format' or 'structure' means or that some terms aren't specific. Please learn how to program before talking about programming.
So, rather than actually explain what Wikipedia means with terms such as "data organization" and "storage format", you just dismiss the whole thing with an ad hominem.
From HN guidelines:
Exactly this.