Sé que es una vieja pregunta, pero quizás alguien podría agregar más ideas.
NB: El siguiente sería en realidad sólo tiene sentido para un subconjunto específico de casos de uso:
Si el requisito incluye altamente superpuestos juegos de llaves (en el caso extremo del mismo conjunto de claves para todos los mapas) entonces una solución efectiva muy podría ser "externalizar" las claves con respecto a los mapas y hacer que los mapas solo contengan valores, en una matriz.
La implementación no debe depender "estructuralmente" del factor de superposición, pero la mía funciona mejor cuanto más se superponen las claves. Como era de esperar
No puedo dar detalles exactos de mi implementación, pero es importante tener un mecanismo adecuado para traducir claves (almacenadas fuera de su objeto de mapa) a índices en la matriz de valores, permitiendo también que la matriz de valores permanezca compacta, es decir, tienen una longitud de cinco si su mapa contiene cinco asignaciones.
Digamos que las claves para todos los mapas se sientan en un mapa separado, asignado a los números. Entonces, se trata de tener una forma de relacionar los números y los índices de matriz.
Lo siento si esto no es lo suficientemente específico, pero pensé que la idea es interesante y simple al mismo tiempo, y podría ser utilizado como una dirección alternativa en el desarrollo de una memoria eficiente mapa.
vez más, es inherentemente adecuado para los casos de uso altos "solapamiento" clave, sino que es genérico. Puede sufrir problemas de rendimiento si la superposición es demasiado baja, según los detalles de implementación.
no creo un mapa basado en una lista enlazada sería el "más pequeño". Crearía una matriz basada en sin los objetos de entrada (es decir, los valores se almacenan directamente en la matriz). Esto significa que las colisiones se pondrán feas, pero hay formas de evitar esto. –
La semana pasada hice una implementación de exactamente este Mapa (para que no estés solo con tus necesidades). Desafortunadamente, la implementación no es de código abierto. Logré reducir el tamaño requerido del mapa a 16 (para el objeto de mapa) + 16 (para la matriz, redondeado hacia arriba) + 8 * 'size' (para los contenidos de la matriz). Ese es el uso de memoria más bajo que puede obtener, a menos que desee operar directamente en la matriz utilizando solo métodos estáticos, lo que le ahorraría otros 16 bytes por mapa. Pero en ese caso, ya no sería una implementación de la interfaz 'Map'. –