Add unit test that confirms performance on large system

[rsdefever]

(Somewhat abstract) idea: Add unit test(s) to make sure that new features don't negatively affect the performance of GMSO. I'm not exactly sure what this looks like, but something along the lines of building a large system and ensuring the time doesn't exceed some limit. pytest has timeout capabilities. I could use some brainstorming from others on what the specifics of the test should look like though.

[rmatsum836]

We have something similar on foyer in test_performance.py where we load in a mb.Compound, atom type with foyer, and use pytest.mark.timeout().

[rmatsum836]

@rsdefever Here are several ideas for tests. I think we'll eventually want to test atom-typing with GMSO once it's a supported feature.

• Writers
• Converter from mBuild
• Loading in a large FF XML (OPLS perhaps)

Also, just so we're on the same page, what would we consider to be a large system?

[rsdefever]

@rmatsum836 I would say at least 100k atoms. If we really wanted to push it, then 500k atoms. But 100k atom systems aren't that "big" anymore.

The main thing is to know when we are degrading performance, so we can decide whether or not the performance degradation is worth whatever new feature we are considering.

[rmatsum836]

Makes sense. My concern is the wall time required for operations with 100k atoms. Right now these unit tests would be quite long. I wonder if it's possible to only run these tests on PR builds.

I'm not sure how much we've worried about optimization at this point. I think it makes sense to leave this issue open and adjusts the tests once we're happy with performance. Then the tests can ensure that new features aren't degrading performance.

[rsdefever]

I'm fine with keeping the tests smaller for now, and then adding larger once as we get better performance.