Re: [Algorithms] Complexity of new hardware

[Adrian S. <st...@8m...>]

We do indeed do all of our final loading through reflection-driven
serialization.  The system doesn't require a lot of allocations though.  The
reflection code itself doesn't perform any memory management.  Objects must
be instantiated externally, and neither the serialization code nor the
underlying reflection code care if the addresses it deals with are on the
stack or part of some shared, pooled memory.

There is a cost to loading through the reflection system, however.  It comes
in the form of virtual function calls and small memory moves when memcpy
would suffice.  The biggest cost, I guess, comes from misuse at a higher
level.  It is reasonably efficient to serialize into and out of fields
represented by member variable pointers, but people have a tendency to want
to serialize into fields using non-trivial getters and setters.  Systems
like this that hide complexity also tend to obscure cost.  A hand-written
load function would never recompute cached state after loading each field of
an object, but a poorly written reflection definition that calls a custom
setter for each field might well end up doing that.  We try to encourage
people to think about how the reflection definitions they write will
translate into serialization code, but in the heat of development mistakes
are all too common.

Of course the bulk of our data is in resources like textures and meshes and
none of that is serialized through the reflection system.  Consequently even
though reflection-driven serialization is expensive, it has yet to be the
lowest hanging fruit in any of our profiles.

Adrian


-----Original Message-----
From: Tibor Klajnscek [mailto:tib...@gm...] 
Sent: Sunday, April 19, 2009 2:58 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Complexity of new hardware

I like how you managed to use the brackets and operators in such a way 
that it almost looks like normal code. Makes it much more readable than 
the usual macro voodoo :)

One things always leaves me wondering - do you guys actually do all your 
release build loading through the serialization interface or do you use 
a different approach there? I guess the former, since your net code 
depends on it. I always found these kinds of serialization approaches to 
be way too dynamic (with all the new/delete/smart pointer stuff) to be 
present in the release build where you want your memory to be as static 
as possible. Or is it just not a problem for you in practice?

Cheers,
Tibor

Adrian Stone wrote:
> This discussion has motivated me to finally write up an article on the
> reflection system implemented in Day 1's Despair Engine.  Like Jarkko's,
it
> is implemented purely in C++ without the use of compiler extensions or a
> custom preprocessor.
>
> The article is pretty long, but if you're only interested in the actual
> syntax you can jump straight to the bottom.  Enjoy!
>
> http://gameangst.com/?p=107
>
> Adrian
>
>
>
----------------------------------------------------------------------------
--
> Stay on top of everything new and different, both inside and 
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today. 
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
>   

----------------------------------------------------------------------------
--
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list