xBimTeam / XbimEssentials

A .NET library to work with data in the IFC format. This is the core component of the Xbim Toolkit
https://xbimteam.github.io/
Other
487 stars 173 forks source link

xBIM SDK consuming huge RAM for creating geometry and objects #321

Closed anil1610 closed 4 years ago

anil1610 commented 4 years ago

xBIM SDK consuming huge RAM for creating geometry and objects.

Assemblies and versions affected:

5.1.0.0

Steps (or code) to reproduce the issue:

I am using below code to create geometry and objects. Let me know if the usage is not proper.

IfcStore m_model = IfcStore.Create(credentials, XbimSchemaVersion.Ifc2X3, XbimStoreType.InMemoryModel);

var transaction = model.BeginTransaction("Initialise Model");

// code to AddHeader();

IIfcProject project = m_model.Instances.New();

// fill project fields

// code to AddHistory();

do { // create low level geometries like Ifccartesian points, faceted breps etc

// create shape representation

// create productdefinitionshape

// CreateIfcObject(productdefshape, ifcUID, objectType) } while( object)

transaction.Commit();

m_model.SaveAs(exportIFCProjectName, StorageType.Ifc);

Expected behavior:

Memory consumption should be at least 50% lesser.

anil1610 commented 4 years ago

For creation of 6704 objects and their FacetedBrep geometry it is taking 3.8GB memory. Where as for creating their property data(each object approx 15 properties) and relationships it is only taking 0.2GB Memory.

Note: We recently migrated to xBIMSDK for IFC files writing, previously we were using steptools C++ SDK we got 100% increase in RAM usage when we migrated to xBIM

andyward commented 4 years ago

Can you share some working code and ideally the model. The above code doesn't actually do anything.

Memory usage depends on a huge number of factors so we'd need to see how you're running the code. Best bet is to share a working repo of a full solution (stripped down appropriately).

anil1610 commented 4 years ago

Pls find the zip of working code. The command line argument is output ifc file (Eg: D:\temp.ifc) Please add required xbim and microsoft.extensions.logging references.

For simplicity, The code creates 1000 slab objects, each slab contains a faceted brep of 1000 facets. The memory is shooting close to 4GB with this. App.zip

andyward commented 4 years ago

For reference, a working git repo would be much more useful. That way we know the versions of XBIM you're using. I'm assuming you're using the nuget published version?

I had a quick peak at Program.cs and see you're using the InMemory model and creating everything in a single transaction. You're creating 1000 slabs each with 1000 faces, each face with unique points & loops - and then you're creating multiple individual representations.

So Xbim is tracking an in-memory object graph of 1 million * N entities (where N is approx 20+ I'd guess). Plus all the transaction logs. On top of that you're allocating 1 million+ Lists<> in the creation of the Cartesian points . If each face is allocating 1000 bytes, with 1 million of of them, you can see why you'd be in the GB range quickly!

You may get more luck from the Esent DB, (using smaller transactions, and by ensuring you're GC collecting at regular intervals) ... but fundamentally the approach is wrong. If these slabs all have the same geometry you should be using maps

Without maps you'll likely choke any GPU that tries to render it anyway....

anil1610 commented 4 years ago

Thank you for the reply Andy...

We are using the nuget publish version. I could not share working repo... as our company policies may not allow to share it outside.

Using Esent DB and frequent transaction commits brought the memory drastically down

For simplicity I shared a case where I am creating the same geometry in a loop, in our actual scenario it is not the case, each time we will create different geometry. so i could not use maps.

andyward commented 4 years ago

OK. Hopefully you'll not have lots of unique objects with 1000s of faces! If you do, you'll probably want to look at some kind of mesh simplification I suspect.