Hello Marc,
Marc Hofmann wrote:
>> hm, that looks quite strange. You are saying "longer than normal", what
>> are you doing normally and how is this case where you see the delays
>> different?
>
> Here is a print out of the changelist and the time in sec it takes to call
> getChangeList()->applyAndClear() (measured with QueryPerformanceCounter
> under WindowsXP). The last sync takes 0.4s, after that the sync time is
> normal again (under 0.01s). When I run the program again, a "longer" sync
> happens on a different place, it's totally random.
>
> Changed: 233 / AddRefd: 98 / SubRefd: 12 / Created: 57 / Destroyed: 0
> Time: 0.00682698
> Changed: 217 / AddRefd: 98 / SubRefd: 12 / Created: 57 / Destroyed: 0
> Time: 0.00533654
> Changed: 281 / AddRefd: 122 / SubRefd: 15 / Created: 70 / Destroyed: 0
> Time: 0.0053213
> Changed: 281 / AddRefd: 122 / SubRefd: 15 / Created: 70 / Destroyed: 0
> Time: 0.0049716
> Changed: 401 / AddRefd: 174 / SubRefd: 23 / Created: 96 / Destroyed: 0
> Time: 0.4113007
hm, ok for the last case the list is a bit longer, but not so much that
I'd expect such a slowdown.
>> are you sure it is the synchronization that causes the delay (it should
>> not take that long unless you have huge changelists), or could it be
>> something different (texture upload and display list creation come to
> mind).
>
> How large can a changelist become, before it takes too long to merge?
good question, I don't know if anyone has timed this from that point of
view, but my gut feeling is it should not be long as there are only a
few pointers that have to be changed per multi field that needs merging.
> Can
> I assume that applying 100 changed FieldContainer?s takes always an equal
> amount of time?
the time also depends on how many fields of the containers need syncing,
so there is more like a constant amount of work per field.
> What is the best way to guarantee a short merge time (say under 0.1s)?
fewer changes will result in faster syncs, however the change list sizes
you've shown above should not be a problem.
>>> I can provide a minimal example if necessary.
>> That would be helpful, specifically the long sync times are strange.
>
> The program loads in a second thread all objects referenced in "file.lst"
> (1). In the display function I sync and measure the time (2).
ok, thanks for sending the program. I've been away from my keyboard all
day and probably will be tomorrow, so I only looked at it a bit for now
and can not see any obvious problem. I'll take a closer look later this
week.
What compiler are you using, is this with an optimized OpenSG library (I
hear debug versions of the MS c++ std library have not so impressive
performance characteristics...)?
In the meantime I'd be interested to hear if anybody else on the list
has seen something similar or has an idea what might be causing the
slowdowns - I'm a bit puzzled about what is going wrong.
Cheers,
Carsten
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
