Page 3 of 3 FirstFirst 123
Results 21 to 25 of 25

Thread: CLASS vs. OBJECT and memory management

  1. #21
    Actually these shown test aren't so useful because they are poorly implemented. What is wrong with them?
    1. When testing WRITE performance of classes/objects the above tests measure both the creation time and first write to fields together. This of course does not provide real picture. Why? Because most of the measured time is actually spent in class creation. You see the main drawback of classes versus records is the fact that their creations takes longer time than record creation. Why is that.
      Because when creating class you don't just allocate memory for it like with records but you also execute some special initialization code that is required for classes.
      Now if you would split the test to measure class creation and field writing times separately you would see that writing to class fields isn't much slower than writing to record fields if it even is.
    2. When testing array of records tests only perform sequential access but not random access. Sequential access to array items is faster due the fact that arrays are always stored in memory as one single memory block and becouse stem memory also excels in perform in sequential memory access. You can observe this by using some memory diagnostic and measuring utils like MemTest.
    3. There is no test that would measure performance of adding or removing records during run-time. Here arrays lose quite a lot of performance because when removing of items you need to rearrange all other items in order to fill the gap. This can become quite slow when you have huge number of larger records as there is quite a bit of memory that needs to be moved. Also due the fact that arrays are always stored as one continuous block of memory it means that when you are extending the size of that array there needs to be sufficient free space after the existing array for resizing. If there isn't then the contents of the whole array needs to be copied to another location in memory where there is enough free space to hold the entire extended array in one continuous block of memory.
      When using lists of classes the above mentioned drawback are barely noticeable because their internal arrays only store references (pointers) to these classes so rearranging their items does not require so big memory movements. Also the data of these classes doesn't have to be stored in one continuous memory block.
    4. Another thing that can screw up tests results is doing random number generation inside the test method/loop itself. Why? Because time taken for generating single random number can vary quite a lot. Of course it most depends on what kind of random algorithm is being used. And it can also depend on whether your CPU perhaps have built-in support for random number generation. So I strongly recommend you generate all needed random numbers before testing and then read them from memory during the testing itself.
    5. And finally the problem of all of the above tests is that they are to short. What do I mean with that? Today's computers are made for multitasking which means that it is not necessary that when you are performing the test your application will be given all the available processing power of CPU core. Not to mention that since most modern CPU use automatic throttling to achieve better power saving it is not necessary that the CPU is working at max speed at the time when you are performing your tests. You can observe this by starting the above test multiple times where you will see varying results.
      So in order to get more accurate results it is best to make sure that the test are running for longer time or are repeated multiple times and then average time is calculated from the results.
    Last edited by SilverWarior; 17-07-2017 at 04:30 PM.

  2. #22
    Very good, very good.

  3. #23
    1) If is class creation and destruction slow - during game loop it's no win. In case that you need some pre-generated data like tilemap, so you can wait xxx ms with classes or have it done until 1 ms with simple array of records.
    2) If you mean access to list of entities by some ID so it depends if you need go through the list or how it's done.
    And somehow I doubt that you can get the result faster by using classes.
    3) That's problem, maybe it can be fixed through better/different implementation. With classes don't forget 1)
    4) In my test are no random numbers in the loop

    Everyone can use for game whatever he want, I'm happy with lists of pointers to records for my entities.
    Classes are generating much bigger CPU load (FPC) and so far I have not found any benefits in performance especially if there are thousands of "objects"/game entities there.

  4. #24
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    There's a modern revival of functional programming that has some very interesting points. Even if you're a die hard fan of functional or object orientated coding - there are advantages and 'disadvantages' to both approaches.

    Yes classes are slower to initialise and destroy but when it comes to even fairly recent hardware? the cost is negligible - the vast majority of modern engines and games are object orientated - engines used in games such as the original 'max payne' were amongst the first fully OO engines and we still have OO engines leading the field today. Forget the performance hit, just pre-initialise if you're using thousands of class instances and it won't matter compared to the computationally heavy sections of code.

    Some parts of your design are complex lumbering beasts that are easier to maintain and modify when designed as classes.

    Some parts of your design are time critical or logically flat and functional programming and the minor performance gains are worth losing the inheritance flexibility of high level classes.

    I think a combination of both is a good idea - as a general rule of thumb anything that's being touched many times per frame (such as entities etc) should be as functional as possible and everything else should be as modular as possible.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  5. #25
    By functional programming, are you talking about this?
    No signature provided yet.

Page 3 of 3 FirstFirst 123


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Comodo SSL