Array de Map<Classe, Classe>?

Opa!
Cara, eu estava com essa mesma treta. O que eu fiz, pra reduzir a complexidade do código (e acredito eu que reduziu), foi fazer uma classe com a chave (no seu caso a String) e uma referência para um objeto (o MeuObjeto). Eu não sei os erros e se é ou não aconselhado a fazer assim (alguém me corrija, por favor), mas na hora pareceu o mais fácil.

Não li o artigo do GUJ de autoboxing ( :oops: ), mas parece-me que iterar em listas é mais rápido que maps ou sets. Na verdade, eu nunca parei para comparar, mas pensando bem, acho que são muito próximos. Afinal, usando um HashMap() você iria iterar sobre os values (ou seja, um “único objeto”, como na lista).

Um array de objetos que usam generics? Isso, pra mim, soou meio estranho (mas não ligue porque é tarde da noite).
Eu nunca fiz, mas acredito que seja possível sim. Você iria tratar dos generics e coisas do tipo separado da “lista maior”, ou seja, da lista que possui a lista com generics (nossa :oops: :oops: ).

Desculpe se não consegui ajudar mais.
Abraço.

Entao cara, na verdade eu queria criar Map<String, Object>[] para depois usar
no BeanUtils.populate (talvez vc me de uma ideia de uma maneira mais rápida
e fácil pra alimentar um bean).

A idéia era alimentar uma lista de beans com o array Map<String, Object>[], pq
pelo que entendi do artigo fazer o for na array pura, é mais rapido que numa
collection, e no artigo foi coisa de 5000ms pra 500ms, então pode dar muita diferença
se eu tiver muitos objetos.

Mas a sua idéia de criar uma classe deu certo. Eu fiz uma extendendo Hashtable<String, Object>.

Agora fica uma pergunta, o Hashtable é mais rápido que o HashMap mesmo?

Quantos milhões de objetos tem dentro da sua lista?
Já usou um profiler para saber onde está o problema de performance, se ele existir?

Aliás, você está com um problema de lentidão?

O HashTable é mais lento que o HashMap. Aliás, não se recomenda usa-lo desde o Java 1.2. Ele é considerado uma “legacy collection”, ou seja, está lá só para manter compatibilidade com os sistemas antigos. A razão por trás disso é que todos os métodos do HashTable são sincronizados. Se você não estiver trabalhando com multiplas threads é um overhead (e dos grandes) que você adiciona a toa na sua aplicação.

No caso do map, ainda é possível gerar uma versão dele usando o método Collections.synchronizedMap, e deixar a sincronização só nos pontos onde ela é realmente necessária. Assim, ele acaba tendo uma performance melhor em multiplas threads também. Mas se for esse o seu caso, aí é melhor usar os mapas do pacote java.util.concurrent.

Quanto a performance da iteração do List e do Set. Como o set é implementado como uma árvore binária, os dados não ficam dispostos de maneira continua, como ocorre no ArrayList. Isso pode gerar uma performance ligeiramente menor. Mas estou para ver o dia em que isso será sequer perceptível para um ser humano.

Ótima informação vini, na verdade acho que com muito tempo de uso as maiores listas terão um
número de no máximo uns 200mil objetos.

Mas a minha dúvida é realmente fazer a iteração com List ou array pura, você acha que é
perceptivel a diferença? Ou não vale a pena trocar minha implementação que está feita
com List? Na verdade com cerca 75000 itens o teste com List levou 2,859 segundos, isso melhoraria
se fosse feito com array nativa?

Deve melhorar um pouco sim. Mas é provável que tenha outros pontos no seu sistema que mereçam mais otimização do que esse. Isso só um profiler pode te dizer…

Antes de trocar sua implementação, tenta rodar um.

Cara, com a array nativa (que me resultou em um monte de gambiarra), o tempo dos
75mil objetos foi de 2,485.

Realmente não vale a pena, vou deixar com o List mesmo.

Valeu!!!

Um ArrayList é implementado internamente como um array nativo; então você nem deveria ter muita diferença entre arraylist.get(n) e array[n] exceto, é claro, pelo tempo do “cast” que é feito implicitamente no get.