Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
please take performance into consideration when add new features — Gideros Forum
  • Home
    • ›

    please take performance into consideration when add new features

    XmanXman Member
    edited November 2016 in General questions
    After checking the source code committed, I wonder do we really have to run extra code for a seldom used situation in the basic frequently used api?

    take Sprite.getWidth (not only this method) for example, the most frequently used case is just get the width as fast as possible, if we need to get a non-transformed value, it can use other way easily. Why have to run extra code for such a simple and heavily used api?
    In a game loop, these frequently used api should be implemented as fast as possible.



    It's good to add new features, please take performance into consideration.



    +1 -1Share on Facebook

    Comments

    • piepie Member
      I can't speak about the committed source code because I don't understand most of it :P however I don't see worse performance on my projects compared to previous releases (even before the gideros open sourcing) I experienced only better fps rates so far, so I suppose mantainers are taking performance into consideration: we all should help them though, if you can spot bottlenecks and suggest optimizations I am sure that they will listen :)

      Likes: n1cke

      +1 -1 (+1 / -0 )Share on Facebook
    • XmanXman Member
      Of course, since open soured, the performance have improved a lot by the effects of all the maintainers.
      We should take each step carefully to keep these results.

      For most user, maybe will not notice these extra code run, but it really more or less take time.
      +1 -1Share on Facebook
    • hgy29hgy29 Maintainer
      Yes, @Xman, be sure that we think twice before adding potentitally heavy stuff (well I do personnally!).

      getWidth() has always involved matrix transform as far as I recall, because actual geometry must be transformed according to setScale()/setRotation()/... in order to compute the Sprite's actual width. IMHO it should be cached somehow, but that kind of changes are error prone, and I didn't dare doing them.

      Likes: n1cke, totebo

      +1 -1 (+2 / -0 )Share on Facebook
    • XmanXman Member
      edited November 2016
      @hay29,I do not mean caching a value,I mean overload these frequently used methods to do extras parameters check for most case it is unnecessary in the latest release.

      Is overload a good implementation for lua?
      If it is,all these similar API like getLogicalWidth and getContentWidth, setTexture and setTextureRegion can implemented this way.But it was not.
      +1 -1Share on Facebook
    • EricCarrEricCarr Member
      XMan, can you post the code, and a reference version of the code with ideal modifications so we know exactly what you mean?
      +1 -1Share on Facebook
    • SinisterSoftSinisterSoft Maintainer
      @XMan... The overloading is done at an early section of the code, it's just one or two checks for number/type of parameter. It should not degrade performance that much, but does improve the API. Having more commands would probably degrade performance more if you look at code generated.

      For simple things like the width or position of sprite, when you know there are no transformations, you could cache them in a Lua table anyhow - it could be faster because you don't have to go through the expense of using the Lua C interface.

      I don't have many problems with the speed of Gideros. But I come from a world of 1 or 2 Mhz processors with 4K of RAM and no more than 8 bits to play with - and having to make an arcade conversion run on the thing at 60hz !

      Nowadays I code very lazily and everything runs at 60hz - why shouldn't it? - you have a min of 500Mhz, 512MB Ram, a GPU that can push out thousands of sprites, etc...

      Saying all that, if you want to start sifting over the code looking for obvious optimisations then you should do. Be aware though that you may be wasting your time as some things are coded to make them more maintainable and the compiler will also spot obvious optimisations too and implement them at compile time (eg calling a function that just calls another function - the middle function will be stripped by the compiler).

      Likes: n1cke

      Coder, video game industry veteran (since the '80s, ❤'s assembler), arrested - never convicted hacker (in the '90s), dad of five, he/him (if that even matters!).
      https://deluxepixel.com
      +1 -1 (+1 / -0 )Share on Facebook
    • hgy29hgy29 Maintainer
      I am really much in favor of overloaded/polymorphic API calls, because they make the API smaller (less function names to recall) on the developper side, and the native code easier to maintain.

      However you're right that there may be a very small cpu overhead, but in most (or all) cases where overloading is used and where code needs to be added to check arguments, the extra code is nothing compared to the sum of real function to be performed plus lua to C bridging.

      Likes: n1cke, SinisterSoft

      +1 -1 (+2 / -0 )Share on Facebook
    • XmanXman Member
      edited November 2016
      I know the overhead of type check code is very tiny.I am not absolutely rejecting methods overload,in some situations it is necessary.But for these API like getWidth,getHeight, an optional parameter is really need? If I'm not misunderstood,self:getBounds(self) will get the same result as the extra parameter set to true.the very tiny type check code may never needed for most or all of the situations.
      Maybe I'm Over sensitive on that.

      +1 -1Share on Facebook
    Sign In or Register to comment.