Resultados

As figuras 71a–71c exibem o tempo total de execução das especificações A–L com as implementações de Emeio baseadas no Hibernate, EclipseLink JPA e no interpretador de Litoral.

Em muitos casos, o tempo total de execução com o interpretador no modo sequencial é menor do que o obtido com o Hibernate e o EclipseLink JPA. É bastante provável que isto ocorra porque o ORM com o qual o interpretador foi integrado possui apenas as funcionalidades necessárias à implementação dos benchmarks, enquanto o Hibernate e o EclipseLink JPA implementam uma série de outras funcionalidades que ajudam o desenvolvedor, mas, eventualmente, reduzem o desempenho.

O tempo total de execução das especificações A, D e H com o interpretador no modo concorrente foi 0,9–9,9% maior do que no sequencial. Este aumento ocorre porque a otimização 1 da seção 5.1.1 elimina destas especificações as oportunidades para concorrência. Em casos assim, o aumento no tempo de processamento oriundo do gerenciamento da concorrência não é compensado por uma redução no tempo de E/S, pois as consultas são executadas sequencialmente. Esta observação sugere que o interpretador deveria ser capaz de identificar se uma especificação oferece oportunidades para concorrência. Em caso negativo, o interpretador operaria no modo sequencial mesmo quando solicitado a operar no modo concorrente.

Por outro lado, o tempo total de execução das demais especificações com o inter- pretador no modo concorrente foi 33,3–69,1% menor do que no sequencial. De maneira geral, quanto maiores forem as oportunidades para concorrência (especificações C, G e L), maior é a redução no tempo total de execução.

Em algumas especificações, o tempo total de execução com o interpretador no modo sequencial foi menor do que com as implementações baseadas no Hibernate (especificações A–D e G–H) e EclipseLink JPA (especificações A–C e G). Em outras, foi maior. O pior desempenho foi observado na especificação I, na qual o tempo total de execução mais que dobrou. Entretanto, em todas as especificações que oferecem oportunidades para pré-carregar objetos executando consultas concorrentemente, esta otimização fez com que o tempo total de execução com o interpretador no modo concorrente fosse menor do que com as implementações baseadas no Hibernate (8–62,3%) e EclipseLink JPA (8,1–56,4%).

(a)

(b)

(c)

Figura 71 – Tempo total de execução das implementações de Emeio baseadas no inter- pretador de Litoral, Hibernate e EclipseLink JPA.

5.2 OO7

OO7 é um benchmark livremente inspirado em sistemas de CAD (Computer Aided Design), CAM (Computer Aided Manufacturing) e CASE (Computer Aided Software Engineering). Ele foi projetado para avaliar o desempenho de navegações, atualizações e consultas em OODBMs. Como o interpretador de Litoral influencia apenas o desempenho de navegações, a implementação de OO7 desenvolvida nesta pesquisa, tal como (IBRAHIM; COOK, 2006), se limita a esta parte do benchmark.

Os principais conceitos modelados por OO7 são:

• partes compostas ( CompositePart ) representam primitivas de projeto básicas como, por exemplo, um registrador em um sistema VLSI (Very Large Scale Integration) CAD ou um procedimento em um sistema CASE. Uma parte composta possui uma parte atômica ( AtomicPart ) raiz;

• partes atômicas ( AtomicPart ) representam as unidades que compõem as partes compostas. Em um sistema CASE, por exemplo, elas representariam variáveis, comandos, expressões, etc. Uma parte atômica possui conexões com outras partes atômicas;

• conexões ( Connection ) representam a conexão entre uma parte atômica de origem e outra de destino;

• montagens ( Assembly ) representam construções de projeto de alto nível como, por exemplo, uma unidade lógica e aritmética em um sistema VLSI CAD. Montagens podem ser formadas por partes compostas, caso em que são chamadas de montagens base ( BaseAssembly ), ou por outras montagens, caso em que são chamadas de montagens complexas ( ComplexAssembly );

• módulos ( Module ) representam hierarquias de montagens complexas. Um módulo possui um manual ( Manual ) e uma montagem complexa raiz;

• manuais ( Manual ) representam a documentação de um módulo.

A implementação de OO7 desenvolvida nesta pesquisa adota o banco de dados (modelo, índices e dados) da desenvolvida em (ZYL, 2010). A Seção B.2 exibe suas tabelas

principais. A Figura 72 exibe os comandos SQL que criam seus índices.

OO7 especifica três tamanhos de banco de dados: pequeno, médio e grande. Esta pesquisa, tal como (IBRAHIM; COOK, 2006), adotou o tamanho pequeno. Nele, o banco de dados é populado com 500 partes compostas, 10.000 partes atômicas, 30.000, 60.000 ou 90.000 conexões para cada parte atômica (esta pesquisa adotou 30.000), 729 montagens básicas, 365 montagens complexas e 1 módulo.

1 create index on assembly ( d e s i g n i d ) ;

2 create index on atomic_parts ( builddate ) ;

3 create index on atomic_parts ( d e s i g n i d ) ; 4 create index on composite_parts ( d e s i g n i d ) ; 5 create index on document ( t i t l e ) ;

6 create index on module ( builddate ) ;

Figura 72 – Índices de OO7.

1 visitAtomicPart=toConnections . to . visitAtomicPart ( ) // T1 2 visitAssembly =[

3 subAssemblies . visitAssembly ( )

4 componentsPrivate . rootPart . visitAtomicPart ( )

5 ] 6 designRoot . visitAssembly ( ) 7 8 visitAssembly =[ // T6 9 subAssemblies . visitAssembly ( ) 10 componentsPrivate . rootPart 11 ] 12 designRoot . visitAssembly ( )

Figura 73 – Especificações Litoral que fazem parte de OO7.

OO7 é composto por sete cenários denominados T1, T2, T3, T6, T8, T9 e CU (Cache Update). Os cenários T2, T3 e CU realizam as mesmas navegações que T1 e, adicionalmente, atualizam objetos. Os cenários T8 e T9 consistem em carregar um manual e varrer o seu conteúdo (uma cadeia de caracteres). Como o interpretador de Litoral influencia apenas o desempenho de navegações, esta pesquisa, tal como (IBRAHIM; COOK, 2006), ignora T2, T3 e CU. Ela também ignora T8 e T9, já que estes cenários não oferecem opotunidades para concorrência. A Figura 73 exibe as especificações Litoral que declaram as navegações executadas em T1 e T6. As duas especificações são executadas a partir de um módulo. A Seção B.1 exibe as classes dos objetos pelos quais estas especificações navegam.

5.2.1 Implementação Baseada no Hibernate

A implementação de OO7 baseada no Hibernate sofreu uma única otimização: atributos do tipo II são carregados através de consultas que fazem uso do operador in de SQL para carregar vários objetos, ou seja, a anotação @BatchSize foi adicionada aos atributos anotados com @OneToMany, @ManyToOne e @ManyToMany. A Figura 74 exibe o tempo total de 10 execuções das especificações T1 e T6 com as versões não otimizada e otimizada. A última é 91,5–91,8% mais rápida do que a primeira.

Figura 74 – Resultados da otimização da implementação de OO7 baseada no Hibernate.

5.2.2 Implementação Baseada no EclipseLink JPA

A implementação de OO7 baseada no EclipseLink JPA sofreu a mesma otimização que a baseada no Hibernate. Entretanto, uma limitação do EclipseLink JPA impediu que os objetos referenciados pelos atributos componentsPrivate da classe BaseAssembly e subAssemblies da classe ComplexAssembly fossem carregados através de consultas que fazem uso do operador in de SQL para carregar vários objetos. Mais especificamente, a exceção org . e c l i p s e . p e r s i s t e n c e . exce ptions . QueryException é levantada com o código de erro 6169 quando a anotação @BatchFetch ( value=BatchFetchType . IN ) é adicionada a estes atributos.

5.2.3 Implementação Baseada no Interpretador de Litoral

A implementação de OO7 baseada no interpretador de Litoral sofreu a mesma otimização que a baseada no Hibernate. Entretanto, diferentemente do Hibernate e do EclipseLink JPA, ela não armazena objetos em um cache.

5.2.4 Resultados

A Figura 75 exibe o tempo total de execução das especificações T1 e T6 com as implementações de OO7 baseadas no Hibernate, EclipseLink JPA e no interpretador de Litoral. O tempo total de execução das especificações T1 e T6 com o interpretador no modo concorrente foi 49,5–59,3% menor do que no sequencial.

O tempo total de execução das especificações T1 e T6 com o interpretador no modo sequencial foi menor do que com as implementações baseadas no Hibernate e EclipseLink JPA. A única exceção foi a especificação T6 com o Hibernate. Entretanto, o tempo total de execução com o interpretador no modo concorrente foi menor do que com as implementações baseadas no Hibernate (52,4–58,0%) e no EclipseLink JPA (95,2–96,5%).

Figura 75 – Tempo total de execução das implementações de Emeio baseadas no inter- pretador de Litoral, Hibernate e EclipseLink JPA.

No caso do Hibernate, a redução no tempo total de execução se deve majoritariamente à execução concorrente de consultas. Entretanto, no caso do EclipseLink JPA, a contribuição desta otimização foi minoritária, pois o tempo total de execução com o interpretador no modo sequencial já é muito menor (90,4–91,5%) do que com o EclipseLink JPA.

6 Trabalhos Relacionados

Este capítulo discute trabalhos (Program Summaries, Scalpel, AutoFetch, etc.) que, assim como esta pesquisa, visam aumentar o desempenho de sistemas baseados em ORMs. De maneira geral, eles alcançam este objetivo produzindo consultas SQL que, quando executadas sequencialmente, minimizam o tempo de pré-carregamento de objetos. Um aspecto interessante, evidenciado no Capítulo 5, é que estas consultas, na maioria dos casos, também podem ser executadas concorrentemente, reduzindo ainda mais o tempo de pré-carregamento de objetos.