Hi Sven, Props -- I am setting all properties in the constructor. I am just allowing them to be changed via the API, much like a setter would allow you to change a property value (except I am using public properties for performance reasons to reduce function calls), so I think that is pretty much covered. You also answered the question about delete, which is very useful. Thanks!
Pooling -- I have read about several other projects implementing object pooling to good effects for things such as particle effects, etc, where a large number of similar objects are repeatedly created and destroyed. In addition, there have been people recommending to avoid the use of object literals, array literals, anonymous functions and native functions that create and throw out new objects (splice, slice, etc.) in order to avoid GC in critical areas. I think that these are all pretty specific to games and may be not recommended or useful for other types of applications that are not so performance sensitive (I certainly wouldn't use pooling in other cases). I really appreciate the info you have shared so far! I am interested to learn more about the space leaks you mentioned, if you have any more info on that (or links I can read). On Monday, June 4, 2012 11:28:21 PM UTC-7, Sven Panne wrote: > > Regarding object pooling: What you describe is exactly one of the use > cases where one should *not* use object pooling. Incremental collectors are > very good at disposing short-lived objects without any noticeable pauses, > so unless you are doing heavy resource acquisition on object creation, > don't do pooling. This only leads to a heavier load on the GC, can easily > lead to space leaks, and in general a good pooling strategy is not that > easy as it might sound. If your program's performance is really, really > bound by object creation, an ugly, but more promising route is to go "the > imperative way", avoiding object creation as much as possible and mutating > objects like hell. But in general that means restructuring your program, > which might be hard, so I would only do this when I'm totally sure about > the bottlenecks. > > Regarding property types: I very much doubt that there are clean use cases > of a "flexible API", where some property values are set in the constructor > and some later. Things like this are a strong hint that the API has a flaw, > and leads to obscure rules like "Don't call the foo function before bar and > baz have been called on the object". Break down the objects/classes/..., > and this becomes a non-problem. > > Cheers, > S. > > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
