just ran your mxs version giving the following result
time:189464 ram:8466104L faces:3551232 elements:1734
so on this machine the sdk runs 40x faster
thought it was a bit slow so restarted max an it 20x slower than the sdk which is pretty typical for dedicated mxs extension functions.
I get this values:
time:20391 ram:335283584L faces:3551232 elements:1734
They seem to be too distant one from the other, and I am not running a super clocked CPU, so I don’t understand such a big difference.
Used memory seems too low in your case too. Are you dynamically allocating the Heap?
in 2015 i get
time:50891 ram:335207075L faces:3551232 elements:1734
though the sdk is about 1650
System memory usage for heavy operations exists of course. the same as just holding a heavy mesh (or tons of meshes) in the scene.
but this memory doesn’t leak and doesn’t need to be added in run-time instead of mxs memory.
any increasing of mxs memory in run-time sooner or later ends with max crash. and of course any increasing slows everything down. that’s why i always check how much memory my mxs method (function) takes.
this runs about 20% quicker
def_visible_primitive(getMeshAllElements2, "getMeshAllElements2");
Value* getMeshAllElements2_cf(Value** arg_list, int count)
{
check_arg_count(getMeshAllElements2, 1, count);
Mesh* mesh = get_meshForValue(arg_list[0], MESH_READ_ACCESS, NULL, getMeshAllElements2);
int numf = mesh->numFaces;
BitArray faces(numf);
int numv = mesh->numVerts;
Tab<Tab verts;
verts.SetCount(numv);
BitArray vbits(numv);
vbits.SetAll();
one_typed_value_local(Array* result);
vl.result = new Array(0);
for (int i = 0; i < numf; ++i)
{
Face& f = mesh->faces[i];
for(int k = 0; k < 3; ++k)
verts[f.v[k]].Append(1, &i);
}
BitArray fbits(numf);
for (int i = 0; i < numf; i++)
{
if(faces[i]) continue;
fbits.ClearAll();
Tab<int> element;
element.Append(1, &i);
for (int j = 0; j < element.Count(); ++j)
{
int fi = element[j];
if(faces[fi]) continue;
Face& f = mesh->faces[fi];
faces.Set(fi);
for (int k = 0; k < 3; ++k)
{
int v = f.v[k];
if (vbits[v])
{
for(int n = 0; n < verts[v].Count(); ++n)
{
int fi = verts[v][n];
fbits.Set(fi);
element.Append(1, &fi);
}
vbits.Clear(v);
}
}
}
vl.result->append(new BitArrayValue(fbits));
}
return_value(vl.result);
}
still doesn’t solve the slow down over time though, my guess is tab::append is slowing down as max’s heap becomes fragmented and the memory manager is shifting stuff around finding continuous blocks large enough for the ever expanding tabs.
how is about to destruct a tab with vbits clear:
vbits.Clear(v);
verts[v].~Tab();
might it help to free memory?
and destruct the verts tab at the end…
verts.~Tab();
usually i don’t do destruction for tabs but i’ve never met this progressive slowing down effect before (didn’t check it for sure)
it’s probably indirectly related to the mxs object construction & delete objects beforehand maybe (I don’t often have to deal with meshes with these many faces).
some time gained on this one
def_visible_primitive(getMeshAllElements2, "getMeshAllElements2");
Value* getMeshAllElements2_cf(Value** arg_list, int count)
{
check_arg_count(getMeshAllElements2, 1, count);
Mesh* mesh = get_meshForValue(arg_list[0], MESH_READ_ACCESS, NULL, getMeshAllElements2);
int numf = mesh->numFaces;
BitArray faces(numf);
int numv = mesh->numVerts;
Tab<Tab< int > > verts;
verts.SetCount(numv);
one_typed_value_local(Array* result);
vl.result = new Array(0);
for (int i = 0; i < numf; ++i)
{
Face& f = mesh->faces[i];
for(int k = 0; k < 3; ++k)
verts[f.v[k]].Append(1, &i);
}
for (int i = 0; i < numf; i++)
{
if(faces[i]) continue;
Tab<int> element;
element.Append(1, &i);
for(int j = 0; j < element.Count(); ++j)
{
int fi = element[j];
if(faces[fi]) continue;
Face& f = mesh->faces[fi];
for(int k = 0; k < 3; ++k)
{
int v = f.v[k];
if(!verts[v].Count()) continue;
element.Append(verts[v].Count(), &verts[v][0]);
verts[v].SetCount(0);
}
faces.Set(fi);
}
BitArray fbits(numf);
for(int i = 0;i < element.Count(); ++i) fbits.Set(element[i]);
vl.result->append(new BitArrayValue(fbits));
}
return_value(vl.result);
}
edit to fix memory leak and slow down!
it’s exactly the same as i wrote first time. but it didn’t work for me for some reason.
also it’s not safe to zero count because it doesn’t automatically free allocated memory.