Marauroa 3.8: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
imported>Hendrik Brummermann →Performance optimization: async login |
imported>Hendrik Brummermann |
||
| Line 48: | Line 48: | ||
; Details : On login Marauroa has to verify the username and password and check if the account was banned. In addition to that it checks if the account was blocked because of too many failed login attempts. And if all is well, it loads a list of all characters belonging to that account, including character details. All in all this can take up to 100ms on a large database with many logged login events. |
; Details : On login Marauroa has to verify the username and password and check if the account was banned. In addition to that it checks if the account was blocked because of too many failed login attempts. And if all is well, it loads a list of all characters belonging to that account, including character details. All in all this can take up to 100ms on a large database with many logged login events. |
||
: Although login events have always been outside the normal turn loop, they used a common synchronization lock. In Marauroa 3.8 all of this happens without holding the lock. Only the small and very fast step of placing a selected character into the world is synchronized. |
: Although login events have always been outside the normal turn loop, they used a common synchronization lock. In Marauroa 3.8 all of this happens without holding the lock. Only the small and very fast step of placing a selected character into the world is synchronized. |
||
: As a nice side effect: There are many messages exchanged during the login process and since processing of them does not have to wait for the turn to end anymore, logins are a bit faster |
: As a nice side effect: There are many messages exchanged during the login process and since processing of them does not have to wait for the turn to end anymore, logins are a bit faster. If we want to change database storage to a meta model in the future, we will not have to worry about it being a bit slower than the blob anymore. |
||
=== Baking of RPClasses === |
=== Baking of RPClasses === |
||
; Summary : todo |
|||
; Summary : Faster access to inherited attributes. |
|||
; Reason for change : todo |
|||
; Reason for change : Improve performance in games with deep RPClass inheritance hierarchies, many objects, and lots of redundant put() and get() calls |
|||
; Impact on Marauroa users : todo |
|||
; Impact on Marauroa users : New methods in RPClass: bake() and bakeAll(). You don't have to use them but if you do, it will make a snapshot of the inheritance hierarchy to optimize performances. Further changes in super classes will not be propagated to children. |
|||
; Details : todo |
|||
; Details : I was wondering why Marauroa is so much faster on Marboard with 100,000 objects and a turn time of 30ms than it is in Stendhal with less objects and a turn time of 300ms. Using a profiler it turned out that a deeply nested inheritance hierarchy slows down calls to RPObject.get() and RPObject.put() because those calls need to fine the attribute definition (get() because of static attributes and put() in order to validate the datatype). And Stendhal does a huge amount of get()s and put()s every turn. |
|||
: Baking a class is similar to baking a cake: After you have thrown in all the ingredients, the cake is baked which causes the ingredients to melt together. In Marauroa: After all the attributes are defined in the inheritance hierarchy, baking means that the attribute of parent classes are melted into the child classes. Just like you cannot take the eggs out of a baked cake, further changes to attributes in parents of baked classes are not visible. |
|||