Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




JuAn4k4

#46109 No te habrá hecho referral alguien de aquí no ?

1 respuesta
desu

#46111 no. siempre hay que poner referal para tener mas puntos de screening aunque sea mentira.

1 2 respuestas
Sphere

#46112 ¿Y como lo defiendes en la entrevista cuando te pregunten quien te refirió?

1 respuesta
desu

#46113 les digo que les falta calle.

paulinho

.

CiudadanoEj
6
Kaledros

¿Es common practice en Go lo de llamar a las variables con una letra o es que la gente con la que estamos trabajando es imbécil? Si es lo primero tiene cojones el asunto.

2 respuestas
sergioRG

#46117 lo segundo? Creo que es bastante misleading en casi cualquier lenguaje

1 respuesta
Kaledros

#46118 Pues menos mal, porque estoy viendo mogollón de a := s.DoSomething() y tengo ganas de matar ya. Encima no usan la inicial, esa "s" es un handler.

1 respuesta
afhn

Sé que es una pregunta tonta porque es normal que me de java heap en local y en un servidor puede que no me de...
Al final aplicando un algoritmo para una búsqueda exhaustiva de un grafo (al final no me salieron más de 30 líneas de código), tengo una lista con todos los posibles caminos. Estoy guardando todos los caminos en un List<StringBuffer> para tener mayor optimización, tarda 13 segundos en calcular 2,5kk caminos. Hay más de 1 millón de caminos con hasta 35 niveles.

Estoy intentando descomponer esos caminos en un mapa de caminos con todos los nodos.
Lista -> 2kk5
Map<Integer,Integer> -> mapa de nodos del camino; level - nodo
En total son 77kk registros

El problema que estoy teniendo es que, la cantidad de datos es tan grande que me da java heap, y no se me ocurre ninguna solución para evitar eso. Intenté usar objetos, o sea, cada camino es un objeto y ese objeto tiene una lista de los nodos por los que pasa con sus atributos, pero al final ocupaba tanto la lista que se moría la máquina. He intentado optimizarlo para reducir la memoria que ocupa la lista usando una lista o array de mapas, cada mapa es un camino. Pero sigue petando, cuando llega a la iteración >2kk3, da java heap.

Estoy pensando en guardar un json y luego leerlo usando multithreading para luego persistirlo de alguna forma o guardarlo en cache para ser consultado cada vez que se quiera revisar los caminos de X grafo. Es necesario guardar los datos en BBDD puesto que a veces es necesario consultar los caminos y buscar los nodos por los que pasa un camino para estadística, o simplemente buscar nodos por los que se tiene que pasar de forma obligatoria.

La cosa es tener la estructura montada antes de persistir para que se pueda ejecutar nBatch a tiro hecho.
Alguna idea para evitar el java heap? Soy un noob con estas cosas y seguramente se me escape algo.

3 respuestas
Kaledros

#46120 Abre writer, escribe X bytes, cierra writer y repite eso dentro de un for.

1 respuesta
afhn

#46121 lo he pensado, pero eso no penaliza en tiempo? no habrá sobrecarga?

1 respuesta
Kaledros

#46122 Obviamente es más lento que ir metiéndolo en memoria, pero si vas escribiendo en un fichero en batches del tamaño que quieras no te saltará nunca un error de pila.

1 respuesta
desu

Hay varias convenciones habituales.

El receiver siempre suele ser una letra (z *Writer). Si tienes una interface como Reader o Writer se usa r y w. Y en este caso como el receiver es un *Writer, han usado una z de zip para no colisionar w.w.

El b para bytes o un r para response es tipico y obvio por el contexto, al igual que usar i j z para iterar. Luego segun el dominio hay otros conceptos tipicos que si es algo temporal puedes abreviar, y si es algu que vas a almacenar conviene mantener como en el caso de crypto.

// writeBytes writes a length-prefixed byte slice to z.w.
func (z *Writer) writeBytes(b []byte) error {
	if len(b) > 0xffff {
		return errors.New("gzip.Write: Extra data is too large")
	}
	le.PutUint16(z.buf[:2], uint16(len(b)))
	_, err := z.w.Write(z.buf[:2])
	if err != nil {
		return err
	}
	_, err = z.w.Write(b)
	return err
}

Si una palabra es muy larga usar 3 chars. req cur ctx. U otros tipicos tmp frm dst src dir...

static void io_prep_async_link(struct io_kiocb *req)
{
	struct io_kiocb *cur;

if (req->flags & REQ_F_LINK_TIMEOUT) {
	struct io_ring_ctx *ctx = req->ctx;

	spin_lock_irq(&ctx->timeout_lock);
	io_for_each_link(cur, req)
		io_prep_async_work(cur);
	spin_unlock_irq(&ctx->timeout_lock);
} else {
	io_for_each_link(cur, req)
		io_prep_async_work(cur);
}
}

Luego si estas dentro de un modulo y estructura de datos, usar los prefijos como io en el de atras o aqui el crypto:

static int __maybe_unused crypto_acomp_report(
	struct sk_buff *skb, struct crypto_alg *alg)
{
	struct crypto_report_acomp racomp;

memset(&racomp, 0, sizeof(racomp));

strscpy(racomp.type, "acomp", sizeof(racomp.type));

return nla_put(skb, CRYPTOCFGA_REPORT_ACOMP, sizeof(racomp), &racomp);
}

Luego si tienes un sk_buff se suele mantener el prefijo y coger las primeras letras para el nombre entonces tienes *skb. O el ejemplo de crypto_report_acomp que se convierte en el racomp, Y mantienes el comp porque dentro de crypto tiene sentido.

En el struct por ejemplo nombres completos y claros:

static struct aead_alg crypto_aegis128_alg_simd = {
	.setkey			= crypto_aegis128_setkey,
	.setauthsize		= crypto_aegis128_setauthsize,
	.encrypt		= crypto_aegis128_encrypt_simd,
	.decrypt		= crypto_aegis128_decrypt_simd,

.ivsize			= AEGIS128_NONCE_SIZE,
.maxauthsize		= AEGIS128_MAX_AUTH_SIZE,
.chunksize		= AEGIS_BLOCK_SIZE,

.base.cra_blocksize	= 1,
.base.cra_ctxsize	= sizeof(struct aegis_ctx),
.base.cra_alignmask	= 0,
.base.cra_priority	= 200,
.base.cra_name		= "aegis128",
.base.cra_driver_name	= "aegis128-simd",
.base.cra_module	= THIS_MODULE,
};
2
afhn

#46123 el problema es que va a penalizar demasiado abriendo, escribiendo y cerrando el buffer, piensa que son 2kk5 iteraciones, y cada iteración puede ser desde 5 caracteres hasta 350 caracteres, y tengo visto que son más de 1kk con esa cantidad de caracteres. Al final es no perjudicar demasiado el tiempo que vaya a tardar en procesarse todo.

eondev

#46119 gente que viene de ciencias y acostumbra a escribir con la nomenclatura de variables a letras, esto del software y la legibilidad es muy moderno y secundario para ellos

desu

#46120 Pon un ejemplo de como representas el camino. Como es un nodo? Cuantos posibles nodos tienes tienes?

Usa un tipo de dato que te quepan todos los nodos, si tienes 235 nodos posibles, con 255 valores de un uint8 ya puedes meterlos. Entonces en lugar de strings, cada camino es un []uint8. Una string son 4 bytes, un uint8 son 1 byte. Con un uint16 tienes 65535 nodos posibles, tantos nodos tienes?

Tambien deberiamos ver la estructura / topologia del grafo. En lugar de guardar los nodos del camino quizas es mas facil guardar las direcciones... Cuantos hijos tiene cada nodo? Los puedes ordenar para que siempre tengan la misma estructura? Si es un arbol binario, cada nodo tiene SIEMPRE 2 hijos hasta la root. Te puedes almacenar si ir a la izquierda o la derecha... Y solo te guardas dos valores posibles en 1 byte. Tu set de representacion del camino de neuvo con un uint8 podrias tener 255 hijos por nodo representado.

En conclusion, depende de tu puto grafo de mierda si no lo pones nadie te puede ayudar y todo es especular.

1 1 respuesta
afhn

#46127 son 2k55 caminos
Cada camino es una lista de puntos dentro de ese camino, puede haber hasta 35 puntos.
Cada punto está representado por un Integer que es el nivel, su key, y el identificador de un nodo, que es el value.
Lo que estoy buscando es la mejor forma de almacenar en memoria, o en su defecto en un fichero sin que penalice mucho en tiempo.

joder desu, qué despectivo, me haces daño tete

1 respuesta
desu

#46128 Y que quieres buscar en ese grafo, como ir de nodoX a nodoY de la manera mas corta? o que?

1 respuesta
afhn

#46129 estadística, o saber si X nodos del camino tienen ciertas peculiaridades, y también para lo que comentas. Si al final es por requisito, hay que amoldarse a la mierda de proyectos en los que uno se mete. Tienen una mierda de grafo montado con una complejidad infumable y un esquema de mierda.
No se puede tocar nada porque no hay mucho tiempo para esto, sólo hay que hacer el cálculo y grabar en bbdd.

1 respuesta
Seyriuu

#46112 Yo en España nunca he visto pedir referencias, la verdad.

desu

#46130 pon un ejemplo reducido de tu grafo y lo que quieres sacar. Aparte de caminos cortos entre nodos que son ciertas peculiaridades?

Si tienes nodos directamente conectados y puedes ir en ambas direcciones, 1-2-3 es lo mismo que 3-2-1.

si solo te interesa el camino corto hay algoritmos para ello, podrias tirarlo a parte y alamacenar solo esa informacion.

cada cuanto tiras el algoritmo?

la estructura del grafo cambia o va a cambiar?

que tienes mas nodos o mas caminos? depende de como de conectado este puedes usar unas cosas u otras...

1 respuesta
afhn

#46132 a ver, no necesitas saber la estructura del grafo, el algoritmo que calcula el grafo ya está hecho. Sólo falta una forma de almacenar esos caminos sin que de Java heap. Pero olvídalo. Voy a ver si puedo manejarlo en bytes o escribiendo ficheros batch y luego los leo.

1 respuesta
desu
#46133afhn:

no necesitas saber la estructura del grafo

es lo mas importante...

segun la estructura usaras un algoritmo u otro algoritmo y unas estructuras de datos u otras...

te esta petando porque no estas pensando en ello

como primer consejo piensa en como representar los caminos. la manera en que algoritmo funciona y la manera en que lo guardas no tiene porque ser la misma. por ejemplo.

tu puedes guardar los algoritmos en memoria usando integers y arrays. hacerte una tabla de traducciones integer => string. y despues almacenar en memoria la string. de esta manera tu representacion en memoria seria 4 veces menor.

por eso te he preguntado si esos algoritmos deben re ejecutarse, si la estructura va a cambiar etc... Porque si eso pasa usaras una representacion en memoria u otra. Y lo guardaras de una manera u otra. Porque si no cambia, puedes guardarte los caminos y luego recuperarlos.

1 1 respuesta
afhn

#46134 nada, da igual, ya he encontrado cómo solucionarlo. Gracias igualmente.

2 respuestas
Kaledros

#46135 Pero di como XD

1 respuesta
eisenfaust

#46117 si, es lo suyo

y no entiendo el problema. el coste de escritura y lectura es superior al coste de comprension

desu

#46135 Nada, sin problema. Igualmente:

#46120afhn:

tarda 13 segundos en calcular 2,5kk caminos

Si tardas 13 segundos en ejecutar ni me preocuparia mucho, pero estoy seguro que lo puedes calcular en 1 segundo sin mucha dificultad.

Yo cuando resolvia esto en near real time tenia que ir en <50ms y muchos mas nodos y caminos.

1 respuesta
afhn

#46136 le estaba dando demasiadas vueltas. El cálculo ya me está dando una lista de todos los caminos en un String con todos los posibles nodos. No necesito procesar esa lista e intentar pasarlo a una lista de mapas de nodos. Si lo que quiero hacer es persistir en bbdd, y luego tengo que leer ese mapa, estoy haciendo una lectura x2, con eso estoy penalizando el proceso. Si tuviese que cachear el mapa sería otra cosa.

#46138 Probablemente. Cuando tenga todo montado, iré optimizando el algoritmo, poco a poco. No le pidas demasiado a un fpero. Suficiente he hecho con destruir algo que está mal, que les estaba llevando días, reduciéndoselo a unos minutos.

Kaledros

"Usamos Go por un tema de performace" y "no pasa nada si esta página tarda 200ms en cargar", dicho por la misma persona y referido al mismo proyecto. MCEMPV.

Usuarios habituales