Buen comentario, Alex, estoy muy agradecido que agregues insight valioso en este hilo.
Coincido que se puede tomar un approach más científico y hacer un stress test. Por otro lado, habría que analizar si el servicio se orienta a muchas escrituras en la ED ó a muchas lecturas.
El mapa es O(1) amortizado, aunque es cierto que los strings producen complejidad añadida, dado que se debe hashear y manejar la colisión (elementos con el mismo hash).
Con el el slice entiendo que debes poder llegar a la dirección de memoria más directamente, sin embargo, al agregar un elemento nuevo, es posible que debas reservar otro bloque de memoria más grande y copiar todo lo que tenías (aumentar el capacity), lo mismo sucede cuando eliminas.
Otra opción que, a priori, me parece apropiada, aunque debe someterse a pruebas, es usar una estructura de arbol binario de búsqueda. De esta forma, agregar y eliminar un elemento debería ser O(log2 n) en lugar de O(n), sin necesidad de manejar hashes y colisiones.
Estaría bueno hacer un curso donde se vaya más a detalle con estas cuestiones de Go, estudiar y aplicar optimizaciones en aplicaciones y servicios. Para ahorrar en infraestructura y producir servicios más rápidos en pos de la experiencia del usuario, todo esto suma muchísimo.
De nuevo, muchas gracias por agregar feedback, me sirve mucho.
Te mando un saludo.
