Test the performance of atomistic.StructureData vs orm.StructureData

[mikibonacci]

test if the new StructureData is slower than the original one.

• create a test (not pytest) that does the same thing for both types, N number of structures
• run for 1, 10, 100, 1000 structures
• test with the kinds check

[mikibonacci]

Hi @giovannipizzi, I did some test on the creation of orm and atomistic StructureData, increasing the number of atoms and also the number of properties in the atomistic. These are the results:

I think that the main difference is that for the orm.StructureData we need to loop and call the append_atom method each time, instead of providing already the full list of atoms.
Increasing the number of properties does not change the atomistic StructureData timing in a relevant way.

Just to underline that here I do not define kinds by default, but only if explicitly provided. I think it should be up to the user to provide the correct kinds and related properties.

[giovannipizzi]

So the new is much faster, right? Great! Regarding the kinds, this means you didn't test yet what we discussed yesterday, that is that kinds are always computed and stored in the attributes/properties? But this is still planned right? Good to retest after, as the search for uniqueness could be slow if not implemented optimally

[mikibonacci]

Yes, for now I do not have any automatic kinds assignation nor check for uniqueness.
But both are still planned