3 ms·
> 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'
by fluffybucktsnek 6mo ago
> 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 6mo agoDepends 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 6mo ago> 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.
- CyberDildonics 6mo agoNot every dependency will generate code. Who said that? Furthermore, those dependencies of dependencies are rather small. No, they add up to 50 MB.
- fluffybucktsnek 6mo ago> Who said that? 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.
- CyberDildonics 6mo agoYour 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?
- fluffybucktsnek 6mo ago> 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).
- CyberDildonics 6mo agoThis 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.