Artigos de ‘ago 2010’

English

Core Data over SQLite Performance Tests – Part 3

12agosto

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):

  1. Insert without join tables;
  2. Inserts with tables;
  3. Select without join tables;
  4. 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.

permalink
, ,
Go Tech

Testes de performance do Core Data sobre SQLite – Parte 3

12agosto

Seguindo nosso último post, Testes de performance do Core Data sobre SQLite – Parte 2, quando iniciamos testes de desempenho com o Core Cata, agora continuaremos com os resultados desta análise.

Como definimos anteriormente este teste mostrará o desempenho em 4 situações (veja detalhes no post anterior):

  1. Inserções sem relacionamentos;
  2. Inserções com relacionamentos;
  3. Buscas sem relacionamentos;
  4. Buscas com relacionamentos.

O post anterior mostrou as 2 primeiras situações. Este post mostrará as últimas duas (selects).

1. Buscas sem relacionamentos

Este teste tenta executar buscas sem joins de 2 formas:

  • Busca por atributo;
  • Busca por identificador.

Em cada caso, vemos como o tempo para executar a busca varia com o número de registros da tabela (de 1 até 10000):

a) Busca por atributo

mín 0,007469 s
máx 0,259504 s
média 0,049227 s
total 492,3 s

Como podemos ver no gráfico, quando buscando por um atributo que não esteja indexado o tempo necessário para executar o select varia quase linearmente com o número de registros da tabela. Assim, é fácil pensar em como o desempenho de sua tabela está piorando com o tempo.

b) Busca por identificador

mín 0,000070 s
máx 0,004420 s
média 0,000086 s
total 0,8597 s

Este caso mostra que buscando pelo identificador (indexado), o tempo de busca praticamente não muda com o aumento do número de registros da tabela, uma vez que o tempo médio de busca foi quase igual ao tempo mínimo.

Conclusão

Estes testes resultaram na seguinte tabela:

Teste Tempo Médio por Select Tempo Total
Busca por atributo t1 or 0,049227 s t2 or 492,3 s
Busca por identificador 0,0017 x t1 or 0,000086 s 0,0017 x t2 or 0,8597 s

Como podemos ver, para selects simples (sem joins) sempre que possível devemos usar identificadores para a busca, mas, se precisarmos buscar pelo identificador, não é difícil pensar no desempenho, uma vez que ele aumenta linearmente com o tamanho da tabela.

2. Buscas com relacionamentos

Este teste mostra como o tempo para executar um select aumenta com o número de joins (em cada select) e o número de linhas. O número de joins varia de 0 a 4.

a) Relacionamentos: 0

mín 0,010763 s
máx 0,405039 s
média 0,071537 s
total 7,15 s

Este teste não tem relacionamentos, então o resultado é o mesmo do teste anterior quando buscando por um atributo.

b) Relacionamentos: 1

mín 0,012153 s
máx 0,632435 s
média 0,299673 s
total 29,98 s

Como esperado, com 1 join o tempo médio foi bem maior, 4,27 vezes maior que com 0 joins.

c) Relacionamentos: 2

mín 0,021038 s
máx 0,633293 s
média 0,29986 s
total 29,96 s

Com 2 joins precisamos de quase o mesmo tempo de processar o select, como esperado, uma vez que a engine de busca já entrou o passo de join do processo de busca, o que não ocorre com 0 joins.

d) Relacionamentos: 3

mín 0,025723 s
máx 0,621014 s
média 0,303619 s
total 30,36 s

Com 3 joins o tempo médio foi levemente pior novamente, como esperado.

e) Relacionamentos: 4

mín 0,027883 s
máx 0,64675 s
média 0,316077 s
total 31,61 s

Novamente, com 4 joins o tempo médio foi levemente pior, como esperado.

Conclusão

A seguinte tabela resulta dos testes:

Teste Tempo Médio Tempo Total
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

Como podemos ver, temos uma grande variação de 0 para 1 join, mas uma pequena variação conforme o número de joins aumenta, devido a funcionamento da engine de busca.

Este post, e o anterior, mostraram os testes de desempenho para o Core Data, que nos trouxeram informações para analisar quando usá-lo em um project e qual impacto teríamos quando usando-o.

Os próximos posts apresentarão nossa análise sobre o framework Magical Panda Active Record. Esperamos que você esteja ansioso como nós estamos.

Este post também está disponível em Inglês: Core Data over SQLite Performance Tests – Part 3

permalink
, ,