Following the last post, Core Data over SQLite Performance Tests – Part 2, when we began performance tests with Core Data, now we continue with the results of this analysis.
As we defined before, this test will show the performance of 4 situations (see details on the previous post):
- Insert without join tables;
- Inserts with tables;
- Select without join tables;
- Select with join tables.
The previous post showed the first 2 situations. This time we will cover the last 2 (selects).
1. Select without join tables
This test tries to execute selects without joins in 2 ways:
- Fetch by object’s attributes;
- Fetch by identifier.
In each case, we see how the time to execute the select varies with the number of registries of the table (from 1 to 10000):
a) Fetch by object’s attributes
| min | 0.007469 s |
| max | 0.259504 s |
| average | 0.049227 s |
| total | 492.3 s |
As we can see on the chart, when fetching by an attribute that is not indexed the time needed to execute the select varies almost linearly with the number of registries of the table. So, it is easy to think on how the performance of your table is getting worst with the time.
b) Fetch by identifier
| min | 0.000070 s |
| max | 0.004420 s |
| average | 0.000086 s |
| total | 0.8597 s |
This case shown us that fetching by the identifier (indexed), the time to fetch almost do not change with the number of registries, once the average time to fetch was almost equal the min time.
Conclusion
This tests resulted on the following table:
| Test | Average Time per Select | Total Time |
| Fetch by object’s attributes | t1 or 0.049227 s | t2 or 492.3 s |
| Fetch by identifier | 0.0017 x t1 or 0.000086 s | 0.0017 x t2 or 0.8597 s |
As we can see, for simple selects (without joins) when possible we should use identifiers to fetch, but, if we need to fetch by an attribute, it’s not hard to think about the performance, once it increases linearly with the size of the table.
2. Selects with join tables
This test shows how the time to execute a select increases as the number of join tables (in each select) and number of rows increases. The number of joins varies from 0 to 4.
a) Joins quantity: 0
| min | 0.010763 s |
| max | 0.405039 s |
| average | 0.071537 s |
| total | 7.15 s |
This test has no joins, so the results is the same from the previous test when fetching by an attribute.
b) Joins quantity: 1
| min | 0.012153 s |
| max | 0.632435 s |
| average | 0.299673 s |
| total | 29.98 s |
As might be expected, with 1 join the average time to a insert was much worst, about 4.27 times greater than with 0 joins.
c) Joins quantity: 2
| min | 0.021038 s |
| max | 0.633293 s |
| average | 0.29986 s |
| total | 29.96 s |
With 2 joins we needed almost the same time to process the select, as expected, once the fetching engine has already entered on the process’ join step, what is not needed with 0 joins.
d) Joins quantity: 3
| min | 0.025723 s |
| max | 0.621014 s |
| average | 0.303619 s |
| total | 30.36 s |
With 3 joins the average time was slightly worst again, as we might expect.
e) Joins quantity: 4
| min | 0.027883 s |
| max | 0.64675 s |
| average | 0.316077 s |
| total | 31.61 s |
Again, with 4 joins the average time was slightly worst, as we might expect.
Conclusion
The following table results from the tests:
| Test | Average Time | Total Time |
| 0 joins | 0.071537 s | 7.15 s |
| 1 join | 0.299673 s | 29.98 s |
| 2 joins | 0.29986 s | 29.96 s |
| 3 joins | 0.303619 s | 30.36 s |
| 4 joins | 0.316077 s | 31.61 s |
As we can see, we have a great variance from 0 to 1 join, but a small variance as the number of joins increases, due the way the select engine works.
This post, and the previous one, showed performance tests for Core Data that bring us information to analyse when use it in a project and what impact we would have when using it.
The next posts will present our analysis over the Magical Panda Active Record framework. We expect you are anxious as we are. Stay tuned!
This post is also available in Portuguese: Testes de performance do Core Data sobre SQLite – Parte 3.
