but this memory is mostly the size of returned mxs array of bitarrays.
i don’t use it this way in my tools. i have my own class BitArrayTab (which is an array of only bitarray type items)
in this case the memory usage is almost ZERO
your machine is a bit faster than mine I get
time:4995 ram:74556L faces:3551232 elements:1734
time:6246 ram:74372L faces:3551232 elements:1734
time:7362 ram:74372L faces:3551232 elements:1734
time:8778 ram:74372L faces:3551232 elements:1734
get progressively slower an leaks memory like a sieve !
time:9024 ram:74372L faces:3551232 elements:1734
i have no idea why it’s progressive slower… but honestly i did do a profiling. i could put some sh*t in the code.
about my machine… sorry
what do you get with a more “trad” version
def_struct_primitive(meshop_getElements, meshop, "getElements");
Value* meshop_getElements_cf(Value** arg_list, int arg_count)
{
check_arg_count(getElements, 1, arg_count);
Mesh* mesh = get_meshForValue(arg_list[0], MESH_READ_ACCESS, NULL, getElements);
AdjEdgeList ae(*mesh);
AdjFaceList af(*mesh, ae);
int numfaces = mesh->getNumFaces();
BitArray faces(numfaces);
BitArray elementfaces(numfaces);
one_typed_value_local(Array* result);
vl.result = new Array(0);
for(int i=0; i < numfaces; ++i)
{
if(!faces[i])
{
elementfaces.ClearAll();
mesh->ElementFromFace(i, elementfaces, &af);
vl.result->append(new BitArrayValue(elementfaces));
faces |= elementfaces;
}
}
return_value(vl.result);
}
this is about the same what i do in my sdk version.
i have ~1800ms for 3.5M mesh
yeah it’s difficult to know whether AdjEdgeList & AdjFaceList are not “overkill” for ElementFromFace and quick tests susgests that collecting the final array takes about 25% of the time.
that’s why i wrote my version of mxs array. it’s exactly the same as mxs array but doesn’t do automatic cast to mxs array. it remains a class which i can get and pass to another function.
making an Array* value in sdk is slow.
If we had the need I would probably make a modifier to select elements based on their count with a tabbing mech to page through them and take mxs out of the equation altogether find more and more my stuff moving to modifiers 😕
the modifiers is another problem…
the most important thing in a modifier is to avoid mesh update on every parameter of paramblocks change. update it only if the mesh really changed. also some modifier types update on time changed, scene redraw, material change, etc. it doesn’t change a mesh… what is a reason to update?
I am a little disappointed with the SDK preformance being just 4-5 times faster than the pure MXS. Where are the days where the SDK was 100X faster? There must be something we are missing.
I am not sure where the bottleneck in the SDK version is, but in the MXS version 35% is just for prebuilding the verts LUT, which also allocates all the memory the algorithm uses.
Anyone whiling to convert it to compiled C#?
when i convert a good mxs code to c++ sdk i usually hope to get it 10x-20x faster. it’s never 100x faster.
another important thing for me is a memory usage. sdk can drop it to nothing.
It might not use memory from the Max Heap, but a 3.5M nested array must use some memory. Were is it stored otherwise?
We usually measure the Heap usage (at least most of the code in this forum measures that), but have you measured the System memory usage? It really can’t be 100Kb for a 3.5M array.