Hi Sven, Object pooling -- If you take a game, for example, where an update loop runs every 33ms or so, GC is one of the major areas that can cause "pausing" and stall the gameplay. Container objects can be created and destroyed at any time and in any number. Even the GC triggered by these objects that are fairly young can lead to paused frames or stalled gameplay. Based on testing, pooling the common game objects and resuing them instead of constanly creating and destroying them led to a marked reduction in GC pauses. This is what led me to go down the pooling path, specific to my case. The creation and destruction of a game object, especially one that participates in an entity system, is expensive to create and destroy.
Property types -- My reason for asking about default property types is due to reading and listening to several presentations where people recommended defining all properties in the constructor. If my object API is flexible, where I do not know when people will set the public property values for a constructed object, I was under the impression that I should still define those properties in the constructor and populate them with default values of the appropriate data type. Later on in the lifecycle of the object, a user will set the updated values based on the timing of the parent code. If this doesn't matter for performance, I would prefer to not define them with local default values, and the user will set/create these properties outside of the constructor. However, if for performance reasons the local default values in the constructor are better for V8 optimization, I would go that route since performance is crucial for me. I hope that makes sense now. Thanks again! On Sunday, June 3, 2012 11:32:45 PM UTC-7, Sven Panne wrote: > > First of all, I would strongly advise against object pooling in a language > with GC. Most of the time it creates far more problems than it solves, and > one of the few valid use cases is when object creation is extremely costly, > like e.g. for data base connections, but it seems that this is not the case > for you. When GC takes a large percentage of the whole runtime, the problem > is often that objects are retained too long, i.e. a performance bug in user > code. Modern GCs should handle rapid allocations of short-lived objects > quite well. > > Regarding your followup question: In general v8 has the best performance > when you pretend that JavaScript has strong typing, so you e.g. only assign > numbers to properties which you intend to use in arithmetic, only strings > to properties used in string operations, etc. > > But assigning dummy values in the constructor looks like a design flaw to > me. Either the object is in consistent state without those properties (then > there is no need to assign anything), or the object's state really needs > some values for these properties (then the dummy values are conceptually > wrong). Why do you want to do these dummy assignments? > > Cheers, > S. > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
