• 2 Posts
  • 34 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle






  • The text of the LGPL actually imposes some very inconvenient restrictions around static linking:

    Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

    https://www.gnu.org/licenses/lgpl-3.0.html#section4

    In order to be compliant, you would have to also ship linkable object files of the proprietary application code alongside the executable.





  • Sounds to me like maybe the sample rate is changing away from what your application expects (44.1 vs. 48 kHz). I used to have this problem with Pulse quite often, but I don’t remember if I fixed it before switching to PipeWire.

    Pulse has a “preferred sample rate” setting in its config files, but it seems to only really be a suggestion, and Pulse tends to ignore it.









  • stop dismissing performance questions

    I did not dismiss it, I said measure the performance yourself.

    Performance matters, learning about performance matters

    Which is why I said you should measure performance. It’s no use waffling about unmeasurable performance gains.

    Did they ask if they should optimize, or did they ask which one generates more performant assembly?

    To be pedantic, GDScript is an interpreted language, and does not generate bytecode or assembly. This means that the code performance is highly dependent on runtime conditions, and needs to be measured in the place where it’s used.

    Maybe they already measured and already knows this is a bottleneck.

    If they already measured, then they would know which one is faster, because they measured it.

    I swear half the reason every piece of modern software runs like shit is because nobody bothered to learn how to optimize

    This is unrelated to what I said, which is “you should measure your performance to see what you need to optimize”.

    There’s tons of little “premature” optimizations that you can do that aren’t evil.

    And all of these optimizations are just as effective after you measure them to see if they’re needed, and they’re no longer premature.

    Estimating time complexity and load size

    Accurately estimating the performance impact of a design choice means the optimization is no longer premature. The rule-of-thumb is about using optimizations without taking appropriate time to their overall performance benefit. The particular question asked by the OP is very very unlikely to have any significant performance impact at all, unless it’s in an extremely hot loop running millions of times per frame, at which point you should measure it to see which one is faster in your use case.