#44970 No es exactamente asi porque en GO tambien tienes la GC. El uso de punteros añade presion sobre la GC. Cuando haces un microbenchmark esto quizas no lo ves, o lo tienes que ver en un tipo de carga especifica.
Tambien si tu tienes un struct de algo como un Mutex, te interesa pasar por referencia para acceder al mutex y no a una copia de este por ejemplo. Lo mismo con otras estructuras que sean punteros.
Pero si, tu mensaje Juan es bastante correcto, en general siempre pasar por copia, ademas hoy en dia, al pasar a la call stack se hace incluso por registro para cosas pequeñas como un int32, int64,... osea que la mayoria de cosas que copias se copian instantaneamente en registro... y vuela.
Esto siempre sera mejor:
struct foo type {
a int
}
que algo con un puntero, que la GC va a tener que tracear:
struct foo type {
a *int
}
ademas de las otras implicaciones que puedes tener al tener el puntero.
#44971 A ver, yo por 10k euros le ofrezco a tu equipo un par de sesiones de Golang.
El tema es como digo que GO es un lenguaje con GC y ese es un tema a considerar.
Luego esta el tema de la stack.
El caso que pones se recomeinda usar * porque imaginate que tienes este codigo:
func main() {
p := &{ a: 10, b :"fooo", c: make([]int, 25) }
}
Por poner un ejemplo, si tu ahora empiezas a pasar esta p copiando de funcion a funcion, vas a estar constantemente copiando el contenido:
func main() {
p := &{ a: 10, b :"fooo", c: make([]int, 25) }
a(*p)
b(*p)
c(*p)
}
E imaginate que a,b,c son funciones que a su vez pasan p de un lado a otro.
Esto lo que hace es que todo el rato hagas copias.
Si tu utilizas un *p todo el rato.
func main() {
p := &{ a: 10, b :"fooo", c: make([]int, 25) }
a(p)
b(p)
c(p)
}
El beneficio es que solo dereferenciaras el contenido de p cuando sea estrictamente necesario:
func b() {
p.c = append(p.c, 123)
}
Vs a estar constantemente dereferenciando, que es lo que le he dicho al fpero de @Soltrac
El problema en este ejemplo NO es copiar, es deferenciar y acceder al valor en este caso dels lice por ejemplo, imaginate que tienes diez mil elementos, tienes que acceder a memoria y luego copiar todo a memoria. esto es carisimo
Tambien entra el tema de que T no es igual a *T. Dentro del sistema de tipado, y esto por ejemplo es importante para diseñar modulos.
En Go si tu has diseñado una funcion asi:
func (b book) IsValid() (bool, InvalidReason) {
if len(a.description) > 50 {
return false, "Description cannot be more than 50 characters long."
}
return true, ""
}
Solo la puedes llamar con book. pero si la diseñas con *book, tienes mas flexiblidad. porque si tienes el * tambien tienes el book, pero si tienes el book no tienes xq tener el *. Es decir, tener el puntero te asegura que si tu has ido pasando una funcion en el call stack siempre modificaras el struct que quieres, vs ir pasando copias.
A veces queires algo immutable, a veces no. La immutabilidad tiene un coste de copia y de acceder a memoria y diseñar tu codigo para que devuelvan las funciones el nuevo struct.
El coste mayor siempre es acceder memoria, tu quieres minimizar el acceso a memoria.
Luego esta el coste de la GC, quieres minimizar el uso de punteros.
Y por ultimo estaria el coste de copiar structs enormes, que esto es raro... pero puede ser si tienes un struct de 10KiB. No se que tamaño respecto a tus caches debe ser el struct para que sea problematico la copia, nunca me ha pasado.
