Optimizing Sequences Traversal and Extensibility
•0 likes•16 views
Report
Share
Download to read offline
Yield generators are a well-known programming feature available in most used programming environments such as JavaScript, Python and many others. They allow easy and compact extensibility on streams operations such as on iterators or enumerable types. Yet, two questions arise about their use: 1) are generators the most efficient choice to extend sequences with new user-defined operations? 2) What if the development programming languages does not provide the yield feature, such as in Java? The research work that I describe in this dissertation aims to answer these two questions. To that end, I analyzed two different programming languages designs for a sequence type, Java and Javascript. Also, I studied the state-of-the-art alternatives to the out-of-the-box sequences included in each language, in a set of features, devising benchmarks to analyze their performance with real world usecases, available for developers to use when choosing a sequence type according to their needs. Not only that but, I also propose my own solution of a sequence type, based on a minimalist design that both allows for verboseless extension as well as fluent chaining of new operations. My proposal aims to be as simple and transparent as possible so the developer may clearly understand what he is using. Finally, I answer the question "When should you use parallelism?" with a set of benchmarks that compare Java Streams sequential processing with its parallel counterpart.
Recommended
More Related Content
Similar to Optimizing Sequences Traversal and Extensibility
Similar to Optimizing Sequences Traversal and Extensibility(20)
Recently uploaded
Recently uploaded(20)
Optimizing Sequences Traversal and Extensibility
- 1. Optimizing Sequences Traversal and Extensibility Autor: Diogo Poeira Orientador: Doutor Fernando Miguel Gamboa de Carvalho 1
- 2. 2
- 3. 3 Map Filter Pipeline Animações de Tagir Valeev da JetBrains
- 4. 4 Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array
- 5. 5 Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Alternativas Third-Party Cister.ValueLinq, LinqFaster, LinqAF, StructLinq, Hyperlinq, … Guava, Protonpack, Vavr, Eclipse Collections, jOOλ, StreamEx, … IxJs, Lazy.js, Lodash, Sequency, Underscore, …
- 6. Alternativas Third-Party Cister.ValueLinq, LinqFaster, LinqAF, StructLinq, Hyperlinq, … Guava, Protonpack, Vavr, Eclipse Collections, jOOλ, StreamEx, … IxJs, Lazy.js, Lodash, Sequency, Underscore, … 6 Porquê tantas bibliotecas? Quais as diferenças entre elas? Qual escolher? Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array
- 7. 7 Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array
- 8. 8 Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array
- 9. 9 Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo
- 10. 10 Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 11. 11 Tinyield Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 12. 12 Tinyield Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 13. 13 Tinyield Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 14. 14 Tinyield Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 15. 15 Tinyield Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 16. 16 Tinyield • Traduções complexas Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 17. 17 Tinyield • Traduções complexas • Gerar máquinas de estado complexas Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 18. 18 Tinyield • Traduções complexas • Gerar máquinas de estado complexas • Perca de desempenho Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 19. 19 Tinyield • Traduções complexas • Gerar máquinas de estado complexas • Perca de desempenho Flow Push/Pull Pull Push Pull Eager/Lazy Lazy Lazy Eager Linguagem Módulo Standard .Net System.Linq Java java.util.stream.Stream Javascript Array Extensibilidade yield Classe Protótipo Transparente Não Não Sim
- 20. Quais as características do yield? 20
- 21. Quais as características do yield? 21
- 22. Quais as características do yield? 22 Terminologia • Função geradora “function*”
- 23. Quais as características do yield? 23 Terminologia • Função geradora “function*” • Gerador
- 24. Quais as características do yield? 24 Terminologia • Função geradora “function*” • Gerador • yield
- 25. Quais as características do yield? 25 Terminologia • Função geradora “function*” • Gerador • yield • Output
- 26. Propriedades 26
- 28. Propriedades 28 • Delimitado • Estaticamente tipificado
- 29. Propriedades 29 • Delimitado • Estaticamente tipificado • Objetos/Funções de primeira classe
- 30. Propriedades 30 • Delimitado • Estaticamente tipificado • Objetos/Funções de primeira classe • Stackful
- 31. Stackful 31 Map – Hash Table
- 32. Stackful 32
- 41. Proposta Tinyield 41 Query • Collection Pipeline
- 42. Proposta Tinyield 42 Query • Collection Pipeline • Conjunto de operações completo
- 43. Proposta Tinyield 43 Query • Collection Pipeline • Conjunto de operações completo • Extensibilidade • Protocolo de iteração com melhor desempenho.
- 44. Proposta Tinyield 44 Query – Short-Circuit
- 45. Proposta Tinyield 45 Query – Short-Circuit
- 46. Proposta Tinyield 46 Query – Short-Circuit
- 47. Proposta Tinyield 47 Query - Extensibilidade
- 48. Proposta Tinyield 48 Query - Extensibilidade
- 49. Proposta Tinyield 49 Query - Extensibilidade
- 50. Tinyield - Stackful 50 yield Tinyield
- 51. Tinyield - Stackful 51 yield Tinyield
- 52. Tinyield - Stackful 52 yield Tinyield
- 53. Tinyield - Stackful 53 yield Tinyield
- 54. Benchmarks e Análise de performance 54
- 55. Benchmarks e Análise de performance 55 • Falta de benchmarks
- 56. Benchmarks e Análise de performance 56 • Falta de benchmarks • Kotlin Benchmarks
- 57. Benchmarks e Análise de performance 57 • Falta de benchmarks • Kotlin Benchmarks • Desenho e Implementação de Benchmarks
- 58. Benchmarks e Análise de performance 58 • Falta de benchmarks • Kotlin Benchmarks • Desenho e Implementação de Benchmarks • StackOverflow
- 59. Benchmarks e Análise de performance 59 • Falta de benchmarks • Kotlin Benchmarks • Desenho e Implementação de Benchmarks • StackOverflow
- 60. Benchmarks e Análise de performance Every - Resultados 60
- 61. Benchmarks e Análise de performance Find - Resultados 61
- 62. Benchmarks e Análise de performance Find - Resultados 62
- 63. Benchmarks e Análise de performance Benchmarks com dados reais 63
- 64. Benchmarks e Análise de performance • REST Countries e Last.fm: • “Distinct Top Artist and Top Track by Country” • “Artists who are in a Country’s top ten who also have Tracks in the same Country’s top ten” Benchmarks com dados reais 64
- 65. Benchmarks e Análise de performance • REST Countries e Last.fm: • “Distinct Top Artist and Top Track by Country” • “Artists who are in a Country’s top ten who also have Tracks in the same Country’s top ten” • World Weather Online: • “Query Max Temperature” • “Query Temperature Transitions” • “Query Distinct Temperatures” • Pipeline: Benchmarks com dados reais 65
- 66. Benchmarks e Análise de performance Query Distinct Temperatures - Resultados 66
- 67. Benchmarks e Análise de performance Same Fringe 67 * a * b c * * c a b Tree A Tree B Pipeline:
- 68. Benchmarks e Análise de performance Same Fringe 68 * a * b c * * c a b Tree A Tree B Pipeline:
- 69. Benchmarks e Análise de performance Same Fringe - Resultados 69 Java Javascript .Net
- 70. Conclusões • Compacto • Eficiente • Transparente 70
- 72. Validação • Repositórios Github • Solução Tinyield: Jayield, tinyield4ts e tinyield4net 72
- 73. Validação • Repositórios Github • Solução Tinyield: Jayield, tinyield4ts e tinyield4net • Benchmarks: Java, Javascript e .Net 73
- 74. Validação • Repositórios Github • Solução Tinyield: Jayield, tinyield4ts e tinyield4net • Benchmarks: Java, Javascript e .Net • Benchmarks Parallel Streams 74
- 75. Validação • Repositórios Github • Solução Tinyield: Jayield, tinyield4ts e tinyield4net • Benchmarks: Java, Javascript e .Net • Benchmarks Parallel Streams • Sek: Wrapper ao Sequence do Kotlin para Java 75
- 76. Validação • Repositórios Github • Solução Tinyield: Jayield, tinyield4ts e tinyield4net • Benchmarks: Java, Javascript e .Net • Benchmarks Parallel Streams • Sek: Wrapper ao Sequence do Kotlin para Java • Publicação na DZone – “Bridge the Gap of Zip Operation” 76
- 77. Validação • Repositórios Github • Solução Tinyield: Jayield, tinyield4ts e tinyield4net • Benchmarks: Java, Javascript e .Net • Benchmarks Parallel Streams • Sek: Wrapper ao Sequence do Kotlin para Java • Publicação na DZone – “Bridge the Gap of Zip Operation” • Publicação na InfoQ – “Enhanced Streams Processing with Kotlin’s Sequence Interface” 77
- 78. Validação • Repositórios Github • Solução Tinyield: Jayield, tinyield4ts e tinyield4net • Benchmarks: Java, Javascript e .Net • Benchmarks Parallel Streams • Sek: Wrapper ao Sequence do Kotlin para Java • Publicação na DZone – “Bridge the Gap of Zip Operation” • Publicação na InfoQ – “Enhanced Streams Processing with Kotlin’s Sequence Interface” • Paper na 16ª ICSOFT – “Deconstructing yield operator to enhance streams processing” 78
- 79. Trabalho Futuro • Geração do Advancer 79
- 80. Trabalho Futuro • Geração do Advancer • Eficácia das “Parallel Streams” 80
- 81. Trabalho Futuro • Geração do Advancer • Eficácia das “Parallel Streams” • Aprofundar este estudo 81
- 82. 82
Editor's Notes
- Boa tarde a todos, espero que se encontrem bem. Eu sou o Diogo e venho-vos apresentar a minha Tese: “Optimizing sequences traversal and extensibility”.
- Todas as linguagens de programação incluem um modulo standard para processamento de sequencias de dados.
- Estamos a falar de módulos que incluem um conjunto de funções utilitárias que facilitam o processamento e a manipulação de sequencias de dados, funções como : o map o filter Entre outras É um conceito que existe desde os primórdios do LISP em 1958 e desde então que a maioria das linguagens inclui módulos com este tipo de funções.
- Por exemplo em .Net temos o Linq Em Java as Streams E em Javascript temos os arrays.
- Apesar disso, em cada linguagem surgem bastantes alternativas aos módulos standard, por exemplo: Em .Net temos o LinqFaster, o StructLinq, o Hyperlinq entre outros, Em Java temos o Jool, o Vavr, o StreamEx, etc E em Javascript temos entre outras, o Lodash, o Underscore e o Lazy.js
- Isto leva-nos a algumas questões, nomeadamente: Porquê tantas bibliotecas? Quais as diferenças entre elas? E qual escolher? Para responder, primeiro temos de perceber quais as propriedades dos módulos standard. Por exemplo:
- O Linq e a Stream são de natureza Lazy, já os Arrays são Eager
- O Linq e os Arrays têm flows de pull já a Stream do Java tem um flow de push
- A nível de extensibilidade, para adicionar novas operações em .Net usamos o yield, em Java implementamos uma nova classe e em Javascript estendemos o protótipo do objeto.
- Destes 3 módulos o único que é transparente é o de Javascript, em que a extensão do protótipo não tem mais nenhuma transformação associada. Em .Net o yield é traduzido pelo compilador numa maquina de estados complexa que equivale ao gerador escrito pelo programador. E em Java a operação é implementada através dum Spliterator, que por sua vez é envolvido numa nova Stream que se traduz num ReferencePipeline com ligações encadeadas por cada operação, usando um conceito de Sink para passar os elementos à operação seguinte.
- Na solução Tinyield adotei como requisitos as properiedades
- Lazy, para evitar o processamento desnecessário associado a processar cada operação de forma eager.
- Push flow, por forma a tornar as extensões à API mais concisas
- Extensão yield like, não fazendo uso do yield claro, mas tirando partido da semântica e da forma compacta como se adicionam operações com o mesmo.
- E Transparência, não necessitando de tradução do código das extensões para o engine da travessia da sequencia.
- Ao mesmo tempo, quis descartar soluções que resultassem em traduções complexas das extensões user-defined. Como é o caso do Java em que se faz Wrap ao código num ReferencePipeline, como acabei de dizer, torna-se pouco claro para o programador o que está a acontecer.
- Gerar maquinas de estado complexas. Como é o caso do .Net, ao usar yield. Em que o código que o programador escreve se traduz numa maquina de estados que pouco se assemelha ao código que escreveu.
- E ainda assim, com todos estes requisitos, sem que a solução tenha perdas no desempenho, para que seja uma solução viável para um leque alargado de use-cases
- Então e quais são as características do yield?
- Comecemos por olhar para um exemplo em Javascript duma função geradora da Sequência de Fibonacci.
- As funções geradoras, também chamados de geradores, são identificadas pelo asterisco depois da keyword function e só nestas funções é possível usar a keyword yield, caso contrario a utilização resulta num erro. O function* é o caso de Javascript, linguagens diferentes têm abordagens diferentes claro, por exemplo em C# é identificado pelo Tipo de Retorno IEnumerable.
- O termo Gerador refere-se a computações que produzem valores.
- O argumento do operador yield torna-se num output do gerador
- Referimo-nos a estes outputs como “yielded values”, em português, valores produzidos.
- Com isto conseguimos identificar que o yield é
- Delimitado. Só podemos usar o yield num âmbito que esteja delimitado por uma travessia.
- Estaticamente tipificado, ou seja, sabemos qual vai ser o tipo de retorno do gerador à partida mesmo em linguagens como javascript, o que garante maior confiança no programa.
- Comportam-se como objetos de primeira classe. Interage-se com eles para obter valores e para continuar a travessia da sequencia. E podem ser passados como parâmetro a outras funções ou geradores.
- E Stackful, ou seja, é possível que um gerador chame outro e mantenha o mesmo contexto de produção de valores.
- Olhando para outro exemplo em Javascript sobre esta ultima propriedade. Imaginemos que temos um mapa que representa uma hash table e cujos valores são arrays de items.
- Para percorrer cada elemento de cada array criamos o gerador flatten que itera cada valor do mapa, passando-o ao gerador list Que por sua vez itera o array que recebe por parâmetro e gera cada elemento iterado como output.
- A expressão yield asterisco no gerador flatten deixa-nos delegar a geração de valores a outro gerador, e assim por cada valor que list gera, flatten gera esse mesmo valor e apenas esse valor.
- Foi com base nesta Terminologia e nestas propriedades que surgiu a Proposta do Tinyield
- Começando pelo Yield. Nesta abordagem decidi tirar partido das funções de ordem superior para oferecer um idioma equivalente ao de geradores baseados em yield, sem necessitar de suporte para instrumentação destes operadores por parte do compilador. Esta interface é equivalente a um Consumer em Java, onde o método “accept” se chama “ret”, aludindo a “return”.
- A Interface Traverser representa o protocolo de travessia em massa. Esta interface oferece um único método “traverse” que pode ser equiparado ao método “forEach” da Stream do Java. Usar esta interface é a forma mais eficiente de percorrer os resultados obtidos da sequencia, isto porque o método “traverse”só tem de passar elementos à instancia de Yield que recebe por parâmetro, só retornando depois de passar todos os resultados, ou seja, tem menos mudanças de contexto.
- A Interface Advancer representa o protocolo de travessia individual, ou passo a passo. Esta interface oferece também um único método “tryAdvance” que recebe por parâmetro uma instancia de Yield à qual vai passar o próximo resultado caso ele exista e retorna um booleano que indica se a travessia avançou ou se não existem mais resultados.
- Apesar da travessia em massa ser mais eficiente, a travessia passo a passo continua a ser necessária para certos use-cases, para se manter a propriedade lazy da sequencia, como na operação “Zip”. Esta operação recebe um tuplo de sequencias e combina-as numa sequencia de tuplos. Se só fosse possível fazer travessia em massa, tínhamos de manter um buffer de todos os elementos de cada sequencia e só depois combinar os mesmos numa nova sequencia. Isto tem uma panóplia de problemas, nomeadamente se uma sequencia for mais longa que a outra estamos a processar elementos desnecessariamente, ou se uma das sequencias for infinita o processo eventualmente iria crashar.
- As soluções para este problema passam por usar travessia individual como temos aqui no slide, usar travessia em massa com short-circuit, ou até ambas como irei mostrar mais à frente.
- A classe Query agrupa as interfaces Advancer e Traverser, é a representação de sequencia oferecida pela solução Tinyield.
- O conceito é simples, segue os mesmos princípios do padrão Collection Pipeline, ou seja, é composta por uma fonte de dados, uma ou mais operações intermédias e uma operação terminal.
- Oferece, como era de esperar, um conjunto de funções utilitárias, como o map, filter, reduce, zip, etc.
- Mas o que distingue a solução Tinyield das outras soluções é a sua forma simples e fluente de acrescentar operações à API, ao mesmo tempo que dá primazia ao protocolo de iteração mais eficiente, travessia em massa, fazendo com tenha melhor desempenho na maioria dos use-cases quando comparado com os módulos standard de cada linguagem.
- Um desafio desta solução, foi a forma de fazer curto-circuito da travessia. Isto porque, dando primazia ao protocolo de iteração mais eficiente, existe a possibilidade de não haver travessia individual definida, mas ainda assim, tudo deve funcionar normalmente.
- Para resolver este problema foi criado um método estático “bye” na interface Yield, que lança a mesma exceção leve TraversalFinishError para fazer um curto-circuito à travessia em massa.
- Para completar foi definido também o método “shortCicuit” na classe Query que faz uma travessia em massa mas está preparado para que no caso de uma exceção TraversalFinishError seja lançada, terminar a travessia imediatamente e retornar.
- O outro desafio foi a extensibilidade. Para não limitar o programador às operações oferecidas pela biblioteca, é necessário disponibilizar formas de estender a API da mesma.
- Para esse efeito a solução Tinyield oferece o método “then” que permite aos programadores definirem operações custom de forma fluente. Para o fazer apenas têm de definir um Traverser a partir da Query “Upstream”, ou seja, que define a sequencia até ao uso do método “then”. Esta forma de extensão não cobre todos os casos, nomeadamente casos em que seja necessário travessia individual e para tal o “then” tem um overload que permite definir ambos os tipos de travessia.
- É de salientar o quão concisa esta forma de extensão consegue ser quando a comparamos a outras formas de estender este tipo de APIs . Olhando para o caso da Stream do Java e comparando com o Tinyield conseguimos ver rapidamente a diferença. Imaginando que o Tinyield não oferece a operação zip, se a quiséssemos adicionar, teríamos um troço de código de cerca de 10 linhas sendo que 3 delas são declarações de variaveis, já para adicionar a mesma operação à Stream do Java escrevemos 36 linhas.
- Voltando ao exemplo do list e flatten que vimos antes em Javascript e comparando com a solução para o mesmo problema usando o Tinyield em C#, vemos que:
- Cada lambda retornada delimita o âmbito do gerador e captura os seus parâmetros, representando um closure.
- Estas implementações não precisam de instrumentação da parte do compilador nem de nenhum tipo de primitiva especial como o yield
- É ainda de salientar que o Yield na solução Tinyield é uma instancia da Interface Yield e não uma keyword especial, e que a forma de delegar o contexto de geração de elementos é passando a instancia de yield ao gerador seguinte como vemos na chamada ao list, o que torna a solução, Stackful.
- Para conseguir validar quais as alternativas mais e menos eficientes fui à procura de benchmarks que fizessem estas comparações.
- No entanto deparamei-me com uma ausência de benchmarks que o fizessem, principalmente benchmarks com use-cases de relevo.
- O único que encontrei com algo que achei relevante foram os benchmarks do Kotlin, dos quais ainda retirei algumas ideias, mas ainda assim os use-cases eram muito simples.
- Decidi então criar um conjunto de benchmarks tanto com use-cases simples, como com use-cases complexos onde se utilizam operações personalizadas para que ilustrassem melhor o panorama do mundo real.
- Um dos sítios onde me inspirei foi numa pergunta do StackOverflow que evidenciava não só a ausência da operação Zip na Stream do Java mas também como a sua adição era verbosa e como perdia a fluência do pipeline.
- O autor precisava do Zip para duas outras operações, Every e Find, e com isto em mente decidi criar dois benchmarks que testavam a performance de adicionar a operação zip assim como o uso da mesma nestas operações.
- Nos resultados obtidos para o Every em sequencias de 1000 elementos, conseguimos ver que tanto em Java como em Javascript a solução Tinyield tem vantagem em performance ou no mínimo é equiparável às melhores alternativas. Em Java o Vavr é de longe o menos eficiente, sendo que a performance da maior parte das alternativas é equiparável, as que se destacam com melhor performance são a Sequence do Kotlin, o Eclipse Collections e o Tinyield. Em Typescript o IxJs é a opção menos eficiente, seguida do Underscore e do Sequency. O Lodash, O Lazy.js e os Arrays ES6 são bastante mais eficientes, juntamente com o Tinyield.
- Já em relação aos resultados do Find, em Java a Sequence do Kotlin é muito superior neste use-case e o Vavr muito inferior, o resto das soluções são mais comparáveis umas às outras, ainda assim o Tinyield não é das melhores soluções. Já em Typescript o Tinyield é a melhor solução para sequencias de números ou strings e o Lazy.js é melhor para classes. Por outro lado o Underscore e o IxJs são as alternativas com pior desempenho.
- É também de salientar que para sequencias maiores o panorama muda, e temos as soluções Lazy claramente com melhor desempenho do que as Eager, o que faz sentido. Porque as operações Eager primeiro vão executar o zip para todos os elementos e só depois vão executar o findFirst() o que resulta em bastante processamento desnecessário.
- Para não ficar limitado a use-cases com dados fabricados decidi procurar APIs que fornecessem dados reais, a partir dos quais pudesse desenhar use-cases que fizessem sentido no mundo real. Encontrei 3 APIs, Rest Countries, Last.fm e World Weather Online.
- Combinando os dados da API Last.fm e Rest Countries desenhei 2 benchmarks: Distinct Top Artist and Top Track by Country Que calcula as combinações de: País Melhor artista do País E Melhor musica do País Sem repetir o artista em mais do que um tuplo. E o Artists who are in a Country’s top ten who also have Tracks in the same Country’s top ten que emparelha o País e uma listagem de artistas que está no top 10 desse país e tem também musicas no top 10 do mesmo país.
- Já com recurso à API do World Weather Online desenhei 3 outros benchmarks: Query Max Temperature que encontra a temperatura mais elevada Query Temperature Transitions que conta o numero de transições de temperaturas de dia pra dia. E Query Distinct Temperatures que conta o numero de temperaturas distintas no conjunto de dados analisado Nestes benchmarks fazemos uso de operações custom, como a oddLines, em conjunto com dados obtidos de fontes reais.
- Para o Benchmark Query Distinct Temperatures a solução mais eficiente é o Tinyield, seguido de perto pela Stream e pelo Jool em Java e pelos Arrays Es6 e o Lazy.js em Typescript. Em Java as piores soluções são o VAVR e o StreamEx e em Typescript são o Sequency e o IxJs.
- Outro benchmark que só me ocorreu mais tarde é um algoritmo clássico, o Same Fringe, que dadas duas àrvores
- Valida se as Franjas de ambas são iguais. Este algoritmo é interessante neste caso, porque a computação das folhas é um processo pesado e para além disto o algoritmo faz uso da operação zip que como já vimos, em Java é uma operação custom.
- No que toca a resultados, o Tinyield tem melhor performance para este algoritmo tanto em Java como em Javascript e em .Net. Em Java tanto a Sequence do Kotlin como o Vavr são as alternativas com pior performance, Já no resto das linguagens as alternativas são muito idênticas entre si, com excepção do Sequency em Javascript que também tem boa performance.
- Concluindo. A ideia do yield nasce das corotinas. O Tinyield é a primeira proposta, independente das corotinas, que consegue ser: Compacto na adição de novas operações Eficiente a processar sequencias de dados, como demonstramos num conjunto de benchmarks. E transparente, ou seja, traduzido diretamente no mecanismo interno de Traversal, sem wrappers auxiliares nem maquinas de estado.
- Algumas validações deste trabalho são os múltiplos repositórios Github, nomeadamente:
- Um repositório para a solução Tinyield por linguagem, foram feitos para Java, Typescript e .Net
- Repositórios com benchmarks e a sua analise também por cada linguagem, novamente Java, Javascript e .Net
- Um Repositório com benchmarks que testam os ganhos de performance das parallel streams e a sua analise
- E ainda um repositório para um wrapper fluente ao Sequence do Kotlin para Java, com 2 repositórios de exemplos de utilização. Sendo que alguns destes projetos já têm alguns seguidores, nomeadamente o Jayield, que é o nome do Tinyield para Java, que tem 9 estrelas e o Sek, que é o Wrapper Java para as Sequencias Kotlin, que já tem 5, não é muito, mas são alguns.
- Uma publicação na Dzone que teve mais de 20 mil visualizações, onde respondi a uma pergunta do StackOverflow que evidenciava a falta de uma operação Zip à stream do Java. Esta publicação mostra várias possíveis soluções e demonstra o desempenho de cada uma através de um conjunto de benchmarks.
- Uma publicação na InfoQ sobre como a Sequence do Kotlin é uma alternativa viável à Stream do Java, sendo mais fácil de estender a sua API, com melhor desempenho e, usando um projeto desenvolvido neste âmbito, sem perder a fluência do pipeline.
- E finalmente um Artigo na 16ª Edição da International Conference on Software Technologies, onde exploro as propriedades do yield e a forma como se podem aproveitar as mesmas para trazer mais transparência ao programador, como evidenciei também ao longo desta apresentação.
- Em relação ao trabalho futuro: O facto da extensão da API da solução Tinyield ser feito através do protocolo de iteração em bulk, faz com que não haja tradução direta para a iteração elemento a elemento. Ao dia de hoje é necessário que o programador defina um Advancer, o que por um lado é mais transparente, mas por outro leva a mais esforço por parte do programador. Uma solução para este problema seria gerar esse código através de uma biblioteca de manipulação de bytecode como é o caso da ASM.
- Em relação às parallel streams. Apesar de ter ficado com a ideia de que são pouco eficientes na grande maioria dos use-cases, os use-cases que tenho podem não ser suficientes para se tirar conclusões fortes. Existe alguma convicção na pouca eficácia destas features por parte da comunidade, como é evidenciado em alguns artigos nomeadamente no artigo “A Java™ Parallel Calamity” do Edward Harned, mas ainda assim, este tópico poderia ser melhor testado.
- E isto leva-me ao meu ultimo ponto. Aprofundar este estudo, tanto a nível dos parallel streams que poderiam ter mais benchmarks para recolher mais dados. Mas também como na tradução do Tinyield para outras linguagens como Python ou Go por exemplo, assim como desenvolver benchmarks para estas linguagens e acrescentar às que já temos.
- E com isto dou por terminada a minha apresentação, espero ter sido claro e que tenha sido útil. Muito obrigado!