We have a graph that defines multiple panels to a roof.
Each roof panel is heavily perforated.
Each panel takes 5mins to construct.
When we try to execute the whole graph / roof... GC crashes, presumably due to lack of resources.
Would it be possible to configure the graph to generate the key panel vertices (four per panel) then loop through each panel ?
As each panel is complete, we would export the panel as raw geometry to separate dgn.
When each panel is finished; can we 'flush' any memory or other resources used by GC for the panel generation before starting on the next panel? Or is this done automatically?
GC V8i SS6 standalone
Unknown said:Because GC uses managed dotNet code, memory management is done by the dotNet framework.
Interesting hack now being supported by C#. Span<T> and Memory<T> sounds like it would be useful for speeding up GC, with all those lists and arrays.
Already in GC?
:-) same here. It's always good to know about what interests our users. On the other side, it's also good to know that our development team is very aware of the changes in the technologies they are using.
Bump
dominic SEAH said:Bump
Bump what?
As far as I know, native support for Span<T> and Memory<T> are not available at NET Framework, because no NET Framework 4.x implements NET Standard 2.1 that defines these types. Both Span and Memory types were designed as a part of NET Core 3.0 development (C# version was designed also with a respect to required features and development priorities of NET Core).
Span<T> can be used by NET Framework developers through System.Memory NuGet package, but it's not supported at compiler/runtime level (but inside the library code), so despite of all applied optimization it's not as fast as native Span<T> in NET.Core.
To evaluate whether to use these types (or at least Span as we are on NET Framework, not NET.Core) and what benefit it will bring is not simple and depends on context a lot. The types are not fast itself (or they are fast at the same level as anything else in NET runtime), but when used properly (which can be complex task), they can decrease memory allocation substantially, which is seen by a user as a code speed-up. All examples a have seen so far were about reading huge data stream (typically data from AI systems with tens or even hundreds of GB in size). When data are small (smaller), especially in NET Framework where some implementation overhead exists, the benefit can be not big.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
bumped to align with this post.
GC seems to have perennial speed problems.... I wonder if using dotNET and its GC (Garbage Collector) is becoming a liability.
GC seems to be speedy with basic geometry nodes but struggles with GNT (see post) and I find the Building Nodes.
I wonder if the GNT problem is to do with dotNET's garbage collector which apparently has problems with spotting 'cycle references' which are hidden in container objects (like GNT)? Apparent a problem not resolved until recently in dotNET.
Inability to track whether something in a container references another object will prevent the memory being freed resulting in the app running out of memory.
dominic SEAH said:bumped to align with this post.
Thanks for the link, the videos look impressive.
dominic SEAH said:GC seems to have perennial speed problems
GC are aside from my main interest (unfortunately), because there are too many more important things to learn :-(
So whereas I learned some GC basics, I have never created anything enough complicated to experience serious performance issues.
dominic SEAH said:I wonder if using dotNET and its GC (Garbage Collector) is becoming a liability.
No. GC is just a feature, nothing else. A problem can be when in certain situation it's not used correctly, but I do not think GC is that case.
Moreover, you are merging one specific feature inside used technology with pretty complex products based on many different technologies (C / C++ / managed code / ...) and consisting from more layers (power platform engine, AECOsim layer, GC cooperating with both...).
dominic SEAH said:with dotNET's garbage collector which apparently has problems with spotting 'cycle references' which are hidden in container objects (like GNT)?
Can you explain it and to provide some examples and technical details? What is "apparently"? For me, it seems there is lack of knowledge how GC works, what strategies are used to organize object generations (G0, G1, G2, LOD) etc. When you will implement a code in such way objects will be always referenced, you are responsible for memory wasting, not GC mechanism.
dominic SEAH said:Inability to track whether something in a container references another object will prevent the memory being freed resulting in the app running out of memory.
No such problem exists in NET GC when code is implemented properly, it's nonspecialis vague construction. In addition, there are detection mechanisms and tools that can help you to identify possibly incorrect code, also GC can be monitored and analyzed to go even further in understanding of runtime condition and whether it can be enhanced.
Also things like self-referencing or cycle-referencing are not issue in NET GC from very first version.
Regards,