Hi All,
Marcus Lindblom wrote:
> Carsten Neumann wrote:
>
>> Hello,
>>
>> [email protected] wrote:
>>
>>
>>> Author: cneumann
>>> Date: Mon Jan 19 16:21:48 2009
>>> New Revision: 1667
>>> Trac changeset: http://opensg.vrsource.org/trac/changeset/1667
>>> ViewVC:
>>> http://realityforge.vrsource.org/viewvc/opensg?view=rev&revision=1667
>>>
>>> Modified:
>>> trunk/Source/System/FieldContainer/Misc/OSGFieldContainerUtils.cpp
>>> trunk/Source/System/GraphOp/OSGSharePtrGraphOp.cpp
>>> trunk/Source/System/GraphOp/OSGSharePtrGraphOp.h
>>> Log:
>>> fixed: prevent infinite loops when following pointers
>>> by tracking the set of visited containers
>>>
>>>
>> I forgot to mention in the commit message that this makes the
>> SharePtrGraphOp fairly slow (at also seems to share a *lot* more [1]),
>> do we want to remove it from the default graph ops ?
>>
>>
I would do so, if it's a real serious hit.
> I think it could be useful in those cases where you have loops.
>
> Perhaps softening the perf-hit by:
> * Making the tracking optional?
>
Good idea, but I would make it the default. Infinite loops are just too
nasty. ;)
> * using a hash/unordered set instead of a the log n tree-set? (Or a big
> bitset of all fcids?)
>
Unordered set: agreed. Bitset: might make sense for big comparisons. Not
sure if those are the ones that cost a lot of time.
> * replacing count() == 0 with find() == end() ? The latter ought to do
> less work (if it matters)?
>
In general empty() is supposed to be the most efficient (O(1)) test for
that, AFAIK. count() is only guaranteed to be O(log n). For a tree
structure it shouldn't be though, but in general using empty() is
cleaner, IMHO.
Dirk
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
