This was a fun one. Here’s my newest post on how to dramatically reduce Godot’s build size.

Some sacrifices were made… But the end result is a Godot project that works exactly the same, albeit with slightly worse performance. Hope this can help others in achieving tiny build sizes!

  • popcar2@programming.devOP
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    3 days ago

    Performance testing is a whole can of worms. It’s hard to get an idea of how performance changes because it’ll depend a lot on the nodes and scripts being used. There could be huge regressions in specific cases and functions and no difference in others. Usually you’ll need a suite of tests to see what changed.

    • insomniac_lemon@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      17 hours ago

      Similar but slightly different reply to Kelly’s, not really responding to your comment on testing viability (though I don’t feel like this comment should be a top-level comment).

      It seems to me that at least for opt=size, it actually did improve performance (for a basic benchmark at least) somewhat for low cost compared to no flags. I’m sure this is not as fast as opt=speed, but I would call that more of a trade-off than a sacrifice especially when also considering compilation-time to get a measure of efficiency.

      At least that was my impression with Clang (which I was seeing size-optimized Clang giving decent performance but half the compilation time of default GCC). An efficient middle-ground.

      EDIT: Though this was also for code (via bindings) not Godot/exports themselves, so it could be different (though I’m not sure why unless a difference of defaults).