Dando seqüência ao último post, Testes de performance do Core Data sobre SQLite – Parte 1, no qual introduzimos o Core Data e definimos o ambiente de testes, agora iniciaremos a apresentação dos resultados desta análise.
Assim como definido anteriormente, este teste mostrará o desempenho em 4 situações (veja detalhes no post anterior):
- Inserções sem relacionamentos;
- Inserções com relacionamentos;
- Buscas sem relacionamentos;
- Buscas com relacionamentos.
Este post cobrirá as 2 primeiras situações (inserções).
1. Inserções sem relacionamentos
Este teste tenta executar 10000 comandos inserts de 5 formas diferentes:
- Tamanho do lote: 1; Repetições: 10000;
- Tamanho do lote: 10; Repetições: 1000;
- Tamanho do lote: 100; Repetições: 100;
- Tamanho do lote: 1000; Repetições: 10;
- Tamanho do lote: 10000; Repetições: 1;
Os resultados foram os seguintes:
a) Tamanho do lote: 1; Repetições: 10000
| mín | 0,037017 s |
| máx | 0,571604 s |
| média | 0,047213 s |
| total | 417,3 s |
Como podemos ver no gráfico, temos uma pequena variação entre o tempo das inserções. Embora o valor máximo do gráfico seja 0,57 segundos, a média (0,047 s) foi bem mais próxima do valor mínimo (0,037 s). Também, podemos ver que o tempo necessário para uma inserções não muda significantemente enquanto a tabela aumenta.
b) Tamanho do lote: 10; Repetições: 1000
| mín | 0,051545 s |
| máx | 1,592167 s |
| média | 0,077328 s |
| total | 77,3 s |
Este caso nos mostrou que, aumentando o tamanho do lote para 10 precisamos, em média, de cerca de 1,64 vezes mais tempo para executar este lote. Assim, podemos imaginar que é muito melhor executar um lote grande do que vários lotes pequenos. O teste também nos mostrou que para inserir 10000 registros com tamanho de lote de 10 precisamos de 77,3 segundos, enquanto com tamanho de lote de 1, para inserir 10000 registros precisamos de 417,3 segundos.
c) Tamanho de lote: 100; Repetições: 100
| mín | 0,221817 s |
| máx | 0,733436 s |
| média | 0,276504 s |
| total | 27,7 s |
Novamente, aumentando o tamanho de lote, agora para 100, precisamos de cerca de 3,6 mais tempo por lote do que precisamos com tamanho de lote de 10. Assim, podemos deduzir que o tempo por lote não aumenta linearmente com o tamanho de lote. Mas novamente, o tempo total para executar os 10000 inserts diminuiu (27 s contra 77 s).
d) Tamanho de lote: 1000; Repetições: 10
| mín | 2,341496 s |
| máx | 2,895445 s |
| média | 2,522845 s |
| total | 25,2 s |
Novamente, o mesmo aconteceu. Com o aumento do tamanho de lote para 1000 precisamos de 9,1 vezes mais tempo do que com tamanho de lote de 100. O tempo total foi melhor que o anterior, mas quase o mesmo (25 s contra 27).
e) Tamanho de lote: 10000; Repetições: 1 (10 repetições com banco vazio)
| mín | 19,171194 s |
| máx | 24,020913 s |
| média | 22,2 s |
Desta vez, aumentando o tamanho de lote para 10000 precisamos de 8 vezes mais tempo do que com tamanho de lote de 1000, enquanto poderíamos imaginar que precisaríamos de mais de 9,1 vezes. Assim, levamos somente 22 s para executar os 10000 inserts.
Conclusão
Estes testes resultaram na seguinte tabela:
| Teste | Tempo médio por lote | Tempo Total |
| a | t1 ou 0,047213 s | t2 ou 417,3 s |
| b | 1,83 x t1 ou 0,077328 s | t2/5,40 ou 77,3 s |
| c | 5,86 x t1 ou 0,276504 s | t2/0,066 ou 27,7 s |
| d | 53,68 x t1 ou 2,523 s | t2/0.060 ou 25,2 s |
| e | 470,34 x t1 ou 22,2 s | t2/0,053 ou 22,2 s |
Como podemos ver, para inserções simples (sem relacionamentos) quando aumentamos o tamanho do lote o tempo para executá-lo é maior, mas, o tempo total é menor. Assim, quando usando o Core Data, sempre que possível devemos salvar dados em lotes grandes.
2. Inserções com relacionamentos
Este teste mostra como o tempo para executar uma inserção aumenta com o aumento do número de relacionamentos (em cada inserção) e de linhas da tabela. O número de relacionamentos varia de 0 até 3.
a) Quantidade de relacionamentos: 0
| mín | 0,053622 s |
| máx | 0,626013 s |
| média | 0,068631 s |
| total | 137,3 s |
Como este teste não contém relacionamentos, o resultado é o mesmo do teste anterior.
b) Quantidade de relacionamentos: 1
| mín | 0,617910 s |
| máx | 0,353416 s |
| média | 0,080156 s |
| total | 160,3 s |
Como seria esperado, com um relacionamento o tempo médio de inserção foi 1,17 vezes maior do que sem inserções.
c) Quantidade de relacionamentos: 2
| mín | 0,078214 s |
| máx | 0,559592 s |
| média | 0,109143 s |
| total | 218,3 s |
Com 2 relacionamentos precisamos de ainda mais tempo para processar cada inserção: 1,37 vezes mais do que com 1 relacionamento. Também, podemos ver que parece que, enquanto a o banco de dados aumenta, leva mais tempo para executar cada insert.
d) Quantidade de relacionamentos: 3
| mín | 0,093524 s |
| máx | 0,650233 s |
| média | 0,135843 s |
| total | 271,7 s |
Com 3 relacionamentos o tempo médio foi ainda pior: 1,244 vezes mais que com 2 relacionamentos.
Conclusão
A seguinte tabela resulta dos testes realizados:
| Teste | Tempo médio | Tempo total |
| a | t1 ou 0,068631 s | t2 ou 137,3 s |
| b | 1,17 x t1 ou 0,080156 s | 1,17 x t2 ou 160,3 s |
| c | 1,59 x t1 ou 0,109143 s | 1,59 x t2 ou 218,3 s |
| d | 1,99 x t1 ou 0,135843 s | 1,99 x t2 ou 271,7 s |
Como podemos ver, com o aumento do número de relacionamentos o tempo médio de inserção também aumenta. Este aumento não é linear.
O próximo post apresentará nossos resultados e conclusões para seleções no Core Data, acompanhe!
Este post também está disponível em inglês: Core Data over SQLite Performance Tests – Part 2
