Caio, primeiramente parabéns pela iniciativa e pela bela orientação ao objeto
Verifiquei que está alimentando as coleções desta forma:
for (int i = 0; i < getMax(); i++) {
array[i];
}
ai então eu questiono, será que a iteração do for each pode influenciar na performance? Teria quer ser verificado a questão de performance dos loops também
for (Object i: array ) {}lucasportela me corrija caso eu esteja errado, mas ate o que eu sei, um ForEach de array é convertido para um For comun pela JVM em tempo de compilacao ou runtime. (Nao sei bem em qual dos dois tempos) e esse foi um dos motivos por ter feito com um comando For, pois haveria um delay ao percorrer esse loop usando um ForEach e outro problema é que se vc verificar bem o código verá que o loop é apenas para realizar os metodos “add()” de objetos no array baseado no total de objetos que o usuario digitar, e nisso eu teria que criar um tamanho fixo no array para depois percorrer um ForEach nas Collections que inicialmente estariam sem objetos incluidos e isso causaria um NullPointerException utilizando um ForEach. Agora caso no futuro seja implementado nesse projeto metodos de “get()” para medir a performance de leitura, poderia testar se há uma pequena diferença entre um loop For, ForEach ou ate mesmo um iterator(). 
e obrigado pelo elogio! enfim esse projetinho soh foi um meio de matar a curiosidade sobre como realmente funciona essas Collections e suas respectivas performance. Ta no git, quem quiser colaborar sera bem-vindo!! XD
Por “aquecimento” você precisa entender o seguinte.
A JVM, ao ler um arquivo .class e executar um método, começa inicialmente a INTERPRETAR os bytecodes. Ela faz isso porque muitas vezes um determinado método será executado uma única vez, não tem nenhum loop e o tempo de execução interpretado pode ser inferior ao tempo de compilação para instruções de máquina + tempo de execução do código compilado.
Se o método for executado uma quantidade suficiente de vezes então a JVM “se toca’” e vê que provavelmente você irá executar mais vezes ainda esse método. Aí ela compila esse método para instruções de máquina.
Isso é bem complexo (e põe complexo nisso) porque podemos ter casos em que um pedaço do método continua interpretado e partes do método (tipicamente contendo loops) são compiladas para código nativo.
http://www.java.net/node/671068
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
Nossa muito interessante esse esquema de “aquecimento de método”, me corrija caso esteja errado, mas ao que entendi do que vc disse, a JVM pega os trechos de códigos que mais se repetem e faz um tipo de cache na JVM para dar um desempenho melhor na execução delas, é mais ou menos isso o q eu disse??
Não é um cache; é realmente compilação para código nativo, tal como se fosse em uma outra linguagem como C/C++ ou Delphi. Como essa compilação é relativamente lenta, ela deve ser postergada até quando realmente necessário.