Benchmarks / performance

[iwbnwif]

Have there been any benchmarks / performance tests written for Ponder (or CAMP)? I googled for some but cannot find anything.

I plan to do some basic testing, for example creating 10k objects with Class::construct and populating some properties but don't want to re-invent the wheel.

I see that the Catch test framework has some built-in timing capabilities, so maybe it is something to consider in the unit tests?

[billyquith]

Well, like anything I guess the performance will depend on what you do with the API. After profiling, if your use case is very slow in any area then file an issue.

I'm not keen on putting timing tests in the unit tests. Timing tests are not unit test, they are functional tests and should be run separately. It would be a good idea to add some at some point. One of the issues raised might be the number of allocations (#11). I'm hoping deal with this.

[iwbnwif]

Points taken.

I haven't yet seen any performance issues but my tests have been with relatively few (10 - 100) objects.

My main interest is whether it is significantly slower to create objects and access properties using Ponder than directly with the object. If it is only 10 or even 100 times slower then I don't think that will be a problem, but if it is 1000's of times slower then maybe.

As you say, the best thing is for me to try it and see.

One of the issues raised might be the number of allocations (#11). I'm hoping deal with this.

Great, but please don't remove the std::string access methods.

Ponder is absolutely brilliant and does exactly what I need so thank you very much!!

[billyquith]

What I'm thinking of adding are "identifier traits", then the user can choose which to use, or implement their own. Maybe:

• const char*.
• std::string - similar to now, using string_view to avoid unnecessary copies.
• string_id (hashes, with a string cache).

Additionally it would be nice to track the number of allocations, so perhaps memory management can be added. E.g. if you aren't deleting your metadata it would be more efficient (and faster) to store it in an alloc-only pool.

I put some milestones in, so hopefully will have made some progress by next week.

[billyquith]

If there is a specific issue that needs addressing then add an issue. For now I'll close this as a worry rather than a measured problem. I still consider the API "beta". Don't really want to worry too much about performance until features in place.