GetPropsAsDict very slow when a "long" string property is present & other observations

[kienerj]

While testing something I realized that GetPropsAsDict can be rather "slow" when additional data is present and that data can depend on the source from which the molecule was created. For example cxsmiles coordinates:

It's not specifically the cxsmiles data that makes it slow, and "long" string property will have the same effect and it's additive.

In my case I'm actually just interested in _smilesAtomOutputOrder put the only way to get that as list is to use GetPropsAsDict:

order = canon_mol.GetPropsAsDict(True, True)["_smilesAtomOutputOrder"]

Getting the desired property directly is much faster with predictable performance but then comes as a weirdly formatted string ('[0,1,2,3,4,5,6,7,8,]') and not as a list:

Therefore wouldn't it make sense to have a method GetListProp like the GetIntProp and GetDoubleProp ? That would be more obvious (less hacky) to use and have predicable performance?

P.S:
with a 100 µs difference per molecule applied to 1 Mio molecules that is 100 seconds of wasted compute time.

[bp-kelley]

GetPropFromDict is a pretty heavy hammer, partly because it is converting all properties into python types. In this case you might have better success with using the inbuilt python eval here

m = Chem.MolFromSmiles("C"*50)
Chem.MolToSmiles(m)

%%timeit
l = m.GetPropsAsDict(True,True)['_smilesAtomOutputOrder']
996 µs ± 11.6 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

%%timeit
l = eval(m.GetProp('_smilesAtomOutputOrder'))
60.7 µs ± 727 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

[kienerj]

I ended up using ast.literal_eval is it is safe to use even on untrusted sources.