Adiciona método Contains e marca InArray como deprecado #10
Conversation
Summary of ChangesHello @fm4teus, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! Este pull request otimiza significativamente a verificação de existência de itens dentro de um Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
Olá! Obrigado pela contribuição. A adição do método Contains e a depreciação do InArray é uma excelente melhoria de performance, como demonstrado pelos benchmarks. A mudança na assinatura do método Get em linkedhashmap para retornar um booleano indicando a existência da chave também é uma ótima prática em Go.
Durante a revisão, identifiquei um problema crítico na implementação do linkedHashMap que afeta a corretude e a performance do método Get, e consequentemente do novo método Contains. Também encontrei algumas chamadas de depuração que foram deixadas no código de teste.
Por favor, veja meus comentários nos arquivos para mais detalhes.
| tmp := l.table[hash] | ||
| for tmp != nil { | ||
| if tmp.key == key { | ||
| return tmp.value | ||
| return tmp.value, true | ||
| } | ||
| tmp = tmp.after | ||
| } | ||
|
|
||
| return nil | ||
| return nil, false |
There was a problem hiding this comment.
Olá! A mudança na assinatura do método Get é uma boa melhoria. No entanto, identifiquei um problema crítico de corretude e performance na implementação do linkedHashMap que invalida a premissa de complexidade O(1) para o Get e, consequentemente, para o novo método Contains.
-
Tratamento de Colisão em
Put: O métodoPut(não presente neste diff, mas parte do contexto) não trata colisões de hash. Ele simplesmente retorna se um hash já existe (if _, ok := l.table[hash]; ok { return }). Isso significa que se duas chaves diferentes produzirem o mesmo hash, a segunda chave e seu valor serão descartados, o que é um bug grave. -
Lógica de Busca em
Get: O laçofor(linhas 71-76) itera sobre a lista de ordem de inserção (tmp.after), não sobre uma cadeia de colisões. Isso é incorreto para resolver colisões e degrada a performance de O(1) para O(n) no pior caso, pois pode percorrer grande parte da lista.
Para que o Get (e o Contains) tenha a performance esperada, o linkedHashMap precisa ser corrigido para tratar colisões de hash adequadamente, por exemplo, usando encadeamento separado (separate chaining) para cada bucket no mapa.
Dado que este problema afeta diretamente o objetivo principal do seu PR, recomendo fortemente que a implementação do linkedHashMap seja corrigida.
There was a problem hiding this comment.
tá certo, a intenção dessa lib é implementar uma estrutura de Conjunto, sem itens repetidos
Problema
Método InArray verifica existencia de um item no set, no entanto ele itera por todo o set, por isso sua complexidade é O(n);
Aproveitando o método Get que usa tabela hash foi implementado o método Contains, que resolve o problema em O(1) (desconsiderando colisões de hash aqui)
Benchmark