No busques elementos en un Array!
Vložit
- čas přidán 4. 12. 2023
- Al buscar en los array considera indexar los elementos.
Primer año a solo 49.90 USD con el cupón "portada_yt". Acceso a todos mis cursos: academia.holamundo.io
o aquí: academia.holamundo.io/bundles... - Zábava
1. No es necesario hacer reduce. Puedes usar Map.
2. Funciona solo en casos de particiones heterógenas, donde cada valor es único.
3. El reduce debió haber sido agregado al benchmark.
4. Esta solución duplica el uso de memoria en largos datasets.
5. Usa un argumento función (thunk), exactamente lo mismo se puede hacer en un "for" simple. V8 tiene optimizaciones para for simples.
6. La solución no acepta case insensitve.
Como es reemplazable el reduce por un map?
map regresa una lista y lo que el esta formando es un objeto de {[id]: usuario}
supongo que podria hacer que el map haga pares de key:object y luego wrappearlo en Object.fromEntries, pero no hay mucha diferencia en "readability" o performance no?
Estos son los videos que me hicieron ver entero este canal, espero que estos video no se vuelvan a perder maestro Nico!!! :D
hola estimado, justo ayer en streaming te estaba dando las gracias, ya que para una tarea de base de datos donde no sabia nada de TypeScript y gracias a tu video "Aprende TypeScript ahora! curso intensivo" me salve con un 75 de 100, un abrazo desde viña del mar, Chile.
Hola podría saber donde hace Streaming HolaMundo?
Gracias!!
@@pedroorteganunez4158 acá mismo en el canal de CZcams, activa las notificaciones y te saldrá, además CZcams ahora cuenta con un apartado de en vivo o directos, donde puedes ver los directos pasados
Como adicional, esto se puede analizar facil pensandolo de esta forma, usando el reduce, estamos iterando 1 vez los usuarios (para crear el reduce) y 1 vez la otra lista que queremos marcar con el created_by_user. En cambio si usamos el find, estamos iterando potencialmente todos los usuarios en cada iteración de los elementos que queremos marcar. Es como pasar de tener 2 for uno abajo del otro, a dos for anidados. O sea, a grandes rasgos, el tiempo de ejecución pasa de 2*n a n^2. Esto quiere decir que la alternativa del find es exponencialmente mas lenta
Eso es lo malo de estos videos. No usan ciclos primitivos (2 for's y chan chan), y tiran de cosas que tambien son iteraciones, pero más rebuscadas (find, reduce, map, etc). No digo que esté mal usarlas, pero las explicaciones "primitivas" son importantes para transmitir el problema y su solución.
@@crayder03pienso igual y es por eso que al menos se debe tocar c o c++ leyendo un libro de análisis de algoritmos, bueno así lo aprendí en la universidad
Lo que comentas como primitivo es programación imperativa, las formas de iterar que mencionas entre paréntesis usan el paradigma de programación funcional que bajo a ciertos criterios se puede considerar mucho mejor que el imperativo, búscate las ventajas de la programación funcional @@crayder03
@@crayder03 Pues en mi caso me parece un reto lo que explica el video, no lo comprendí de primeras, pero estuve analizando el porqué y cómo funcionaba y luego comprendí. No considero que eso sea algo malo, uno ya se acostumbra que las explicaciones a veces no vienen con todo fácil y es trabajo de uno el analizarlo todo y así se aprende más.
no tanto porq al utilizar (find, reduce, map, etc) ya estaríamos con programación funcional y eso saca los for prácticamente, ya lo que si deberían leer como funcionan estas y cuando debemos utilizarlos @@crayder03
Podrías compartir cuanto tiempo te toma incluyendo el proceso de indexado con el reduce, para tener un panorama más cercano a solo usar find. Un saludo!
aqui es un problema de estructura de datos , es muy comun actualmente de usar arrays para todo , pero si vas a tener que realizar busquedas o multiples accesos es mejor usar Map u object dado que el acceso es de O(1) , en contra al O(n) esa es la idea , asi que cuando creas la structura de datos debes de pensar en eso y usar o un array o una estructura indexada ese es el problema , tmb puedes usar arboles ,binarios, monticulos , arboles balanceados , listas doble enlazadas ...dependiendo del tamaño y lo deseado multiples escrituras o lecturas o simplemente iteracion array ....
Solo un apunte: al usar un objeto para crear el diccionario de usuarios, limitamos los tipos que podemos usar como clave (ya que todo se convierte a string). Una alternativa es usar el tipo Map, que tiene precisamente la finalidad de indexar objetos en base a una clave, y es más flexible que un objeto plano 🙂.
eso mismo fue lo que pense
Correcto!!
Yo también, pero entiendo el concepto que menciona en el ejemplo, en caso que requiera buscar por otra propiedad del objeto
Exactamente pensaba lo mismo.
Yo no entendí nada
Gracias por el consejo! Demasiado útil para reducir tiempos de búsqueda
Excelente, siempre invesigando sobre velocidad y ahorro. estas son realmente buenas practicas. Saludos Nico!!
Wowo volvió :3 que alegria volver a ver a este grande !!!
Muchas gracias justo lo que andaba buscando para optimizar resultados en mi sistemas
Sos un maldito genio. Genio!!
Directo y práctico. Así los quiero 👍 gracias
Ame, y tambien me encanto el Synthwave de fondo
Una belleza!!! grande!
Wow muchas gracias por esta clase de vídeos.
Está buenísimo esto chabón. Gracias
como se extrañaba este tipo de contenidos
Me gusta ver Hola mundo porque explica tan bien, muy pedagógico a mi parecer 👍
Hola, muy ameno tutorial, estoy aprendiendo rápido, Gracias!
Si el indexado por id coincide con el índice del array original, no hace falta crear otro objeto cuyas llaves son la id, ya que la array original misma sirve para la búsqueda.
luego saca otro video para vender un curso sobre los hash table y además ese consoleTime deberia medir el reduce
@@csnzlatino En este caso el punto no es medir el reduce ya que se asume que este ya esta construido para ser usado multiples veces, por eso el ejemplo hace enfoque en el algoritmo de search que se supone va a ser utilizado en varias ocasiones
@@xdneos si quieres comparar con al método anterior, también tienes que medir el reduce.
Si yo pensé lo mismo. No tiene sentido crear el objeto usersIndexado si ya se puede usar el array original users!
Por eso es común normalizar la data cuando viene de backend, normalizer por ejemplo puede transformar los array en hashTables y eso te salva la vida al momento de interactuar con la data.
Un apunte, un backend nunca debería enviar un array de miles de elementos al front.
@@jcuervasporque?
@@letthesuntalk cambiaré nunca por muy excepcionalmente. Es muy poco probable que el front necesite tanta información. Si vas a montar una tabla, solo necesitas tener los elementos que quepan en pantalla. Si renderizas en un navegador una tabla con cientos de filas el rendimiento va a ser malo, no digamos ya miles. Si es un gráfico, los datos deben llegar ya agregados, no vas a mostrar un gráfico de columnas con 100 columnas en un eje. En definitiva, el front no debería procesar datos, idealmente deben llegar ya procesados y se limitará a mostrarlos. Indexar un array tiene sentido en el backend, pero en el front es más usable un array de, como máximo, unas decenas de datos ya procesados
@@jcuervaspara esas excepciones se usa virtual scroll para que no penalice la performance del front
@@elektropunkk9835 aún así estas enviando más información de la necesaria. El payload de la petición puede ser muy grande. No digo que no se pueda hacer, pero en la mayor parte de los casos es mejor que el front tenga lo justo y necesario
Está genial el aporte 🤩
Yo siempre hacia eso utilizando mapas, pero esta solución está mucho mejor y mas elegante.
Gracias por compartirla
Pero en ese caso deberías de agregar dentro del time() lo que estás haciendo con reduce() por que es un esfuerzo que haces por no usar find
También pensé lo mismo. Al final lo probé en el código, igualmente es mucho mas rápido agregando el reduce dentro del console.time. Yo hice la prueba con 2000 iteraciones; con el método find demora 33ms y con el reduce 7 ms.
@@jesushurtado1560 es correcto lo que dices, aunque de igual manera el punto de vista que comento es lo que se debía hacer en el ejemplo.
Excelente explicación, buen vidio crack!, Saludos.
Esta muy bueno este video. Para la proxima deberias incluir el tiempo que tarda el indexado, asi se tendria una apreciacion mas justa de cuanto tarda en total toda la operacion....
Igual lo que más interesa es el tiempo de búsqueda pq la creación se debería hacer una vez o pocas veces
El indexado es lineal, el filter dentro del map es exponencial, siempre va a ser mejor lo lineal
Claro que es lineal, y claro que va a ser mejor.... Solo digo que se debe contar el tiempo de hacer el index como parte del proceso general!!
Qué es eso de lineal y exponencial?
@@juan7114 Un ciclo dentro de otro ciclo tiene una escala exponencial, porque la cantidad de iteraciones de los ciclos se multiplica
Un ciclo despues de otro (sin anidarse) tiene una escala lineal, porque las iteraciones se suman. Esto los hace mucho mas eficientes
Busca videos de notacion Big O
Caraca! Que dica fantástica!!! Ganhou um inscrito brazuca! 🤘😁
Con el .find estás realizando bucles anidados por lo que el tiempo es O(n^2) en cambio con el .reduce baja a O(n) de ahí la mejora, pero ojo que a cambio la memoria aumenta O(n)
ahí la memoria aumentaría por el mapa que se esta creando de los usuarios? igual pensaba en eso, guardar en memoría un array de 10mil o más igual me parece arriesgado, yo le dejaría la pega de filtrar e indexar a la base de datos.
Y crear el indexado tampoco es gratis, lleva su tiempo y habrá que "recrearlo" o insertar en el lugar adecuado si se modifica, que tambien lleva su tiempo. Todo depende del caso particular a resolver.
Para ser justos, también debería haber tomado el tiempo de ejecución de la función reduce
YO lo veo viable para hacerlo en el servidor que no se haga en el front, porque hacerlo en el front, conlleva memoria por el cliente. Y en otro caso, creería que es más viable de inmediato filtrarlo desde la base de datos, así evitas traerse tanta data y traerla de una vez purgada.
callate
Muy interesante, no nococia el concepto de hacer primero el indice del array y despues buscar mas rapido! Gracias!
Ya hacia falta los videos de este estilo al canal, se extrañan los de indole personal y de motivación. Son tu trademark!. P.D. recuerdo cuando hiciste este video cuando recien llegaste a nueva zelanda. Sin los efectos, ni background como ahora. Era simple pero muy orgánico y con una pieza de información reutil.
Cierto, yo llegue aquí por esos videos. Se extrañan
Hay más variables a tener en cuenta, como en donde vive el índice, el tamaño del array de acuerdo a esto, cuál de los dos arrays a comprar crecerá más, uso mucho esta técnica pero hay que profundizar un poco más al usarla.
Buen video.
El mejor explicandl gracias por este contenido
Excelente contenido. Muchas gracias.
que buen tip y aporte!
gracias. podrias hacer un video de las funciones principales de lodash o un top
Increíble... algún día profe .. algún día
volvistes genial
Que buen video y que buen polerón compa... saludos
muy bueno, gracias!!
Alfin un buen uso práctico a reduce más que sumar todo los números
Que buena idea, si me acuerdo voy a usarla la próxima
Oh guau, recomendando usar un método por sobre otro para eficiencia sin saber cómo están implementados, muy útil.
Hola, Hola Mundo! 😃
Para tomar el tiempo real de la segunda opción con los usuarios indexados, no sería necesario mover el console.time encima del reduce? Ya que este es necesario para poder aplicar el userIndexado. Saludos
Es cierto, pero de todos modos va a ser mucho menos porque con el indexado, tenemos 1 loop que itera todos los usuarios para hacer el reduce, y otro loop que itera todos los elementos que queremos marcar con el created_by_user. O sea 2*n. En cambio usando el find, estamos haciendo una iteración de los usuarios por cada elemento que queremos marcar, o sea n iteraciones de n usuarios, n^2
en un caso de la vida real, probablemente sea una operación que ya tengas guardada en memoria, por lo que no se ejecutaría petición tras petición.
Totalmente de acuerdo @@Titere05 , no digo que esté mal la opción, al contrario, es genial. Simplemente que tampoco estamos mostrando el tiempo como debe ser, ya que deberia agregarse el tiempo para generar el indexado.
Saludos!
Interesante dato. Yo lo uso. Desde que aprendi a programar busque alternativas mas legibles para mi codigo y performance. Buen tips
está chida tu sudadera!!
Muchas gracias
Muchas gracias por tu explicacion, puedes por favor comprartirnos cual tema tienes instalado?
Excelente, gracias
Me encantó!!
Muy bueno gracias
Aalaaamadr3333 como decimos en México!! 😮😮 ... Eres un crack!! ... Quiero aprender a programar y me urgeeee
El dioaaaaacheee que bueno, gracias brot
Pero guenísimo video broo
Excelente, buena idea para no usar los find dentro de un bucle
Es una gran solución para reducir la complejidad en tiempo, pero se sacrifica complejidad en memoria que, en algunos casos, podria ser considerable.
bro y que sugieres en ese caso?
Es que esta mostrando un ejemplo básico (y pensado para que sea fácil de comprender), se asume que en la vida real no es así y que en vez de aplicar transformaciones con un map usaría un generador justamente para evitar el problema de la ram que mencionas.
buen aporte, por ahi estaria bueno calcular la complejidad (alg) y entender a fondo lo que pasa. Saludos y gracias!
Un genio
Cada día me siento mas novato jaja mas videos como este porfa
Sensacional.
*Batallita del dev:*
Una vez hice un programa que trackeaba salas del primer resident evil y cada sala tenía una serie de coordenadas para pintar en el mapa la posición del jugador.
Cada segundo realizaba 60 ops de posicionamiento, pero en vez de crear una bound function o un mapa, hice un listado de if else, en la práctica funciona muy bien, pero realmente a veces me dan ganas de volver atrás y optimizar ese código.
Gracias, pelón, buen tip
GRACIAAAASS AHORA TENGO QUE PONERLO EN 20 REPORTES DE UN SISTEMA WEB EN EL QUE TRABAJA MI EMPRESA, PERO ES NECESARIO
Buen video 👍
interesante, saludos
Probe el código porque me dio curiosidad cuanto tiempo agregaba el Reduce para crear el usersIndexado y no afecto el resultado, es muy eficiente 👏.
También me sirvió para ver la diferencia de potencia entre mi PC y la de Nicolas jajaja a el le tarda 0.4ms y a mi 4ms 😅😅
genial, aprendido
Hola,
Gracias por tus conocimientos compartidos.
Estaba analizando, si al final el tipo de valor de cada elemento del reduce es un object {key: value}
Crees que otra alternativa podria ser crear el listado de User como tipo Object {key, value} de una vez?. Asi evitamos el find y el reduce. Y el key del cada user seria el id. Asi accedemos mediante el key del object. que basicamente es lo que hace el reduce.
Podrias hacer un benchmark para ver si esta solución que te propongo es eficiente?
Saludos
lo ideal es hacer lo que haces una entity en redux con ngrx tener un diccionario donde la clave es el id y el valor el objeto y tener tambien un array con los ids para cuando es util el orden o devolver todos los elementos como un array.
Amo tu remera de demon slayer
hola siento que soy un fracasado y pensé y no servía para nada pero me empezó a gustar la programación gracias a ti explicas de una manera comprensible, entendible pero la verdad aun no elijo a que lenguaje debería entrar pero gracias por hacer ala gente le guste la programación
usa javascript para aprender lo basico, los fundamentos, luego ver por un lenguaje orientado a objeto fuertemente tipado como JAVA. de ahi en adelante cualquier otro lenguaje sera pan comido, asi que profundiza estructura de datos y ejercicios de algoritmos, luego construye una web que haga algo valioso... no las tonteras de poke api. Saludos
En desarrollo te vas a sentir más "fracasado" aún, solo no te desanimes; que sentirse así es parte de la rama.
Yo estoy siguiendo el curso de Ultimate Python que dicta Nicolás, está muy bueno
Hola, pues llevo como desarrollandor junior 2 meses, creo que es verdad lo que comentan arriba, sigo sintiéndome fracasado y que no valgo aun cuando ya logro superar un problema difícil, lo que me ha ayudado es darme cuenta de que no soy el único, que es mejor aprender un poco cada día y seguir adelante, cuando menos lo esperes ya estarás muy avanzado en tu camino! Solo sigue adelante!
A todos nos pasa en algún momento eso de sentirnos fracasados, la cosa está en seguir aunque nos cueste, porque así tmb cuando nos sentimos inútiles, tmb nos sentimos increíbles cuando logramos aprender o superar algo q nos costó
Que buena remera!
Buen video
muito bom!
Crack 🎉
Gracias! Estava com problema de busca de dados em uma tabela que tem milhões de dados e, para essa consulta, tenho que recorrer em todas as linha afim de buscar o registro do usuário em específico.
Excelente maestro, podrias hacer el ejemplo pero con C#?
te amo pelón🤌
Nico saludos desde ECUADOR cachai soy ecuatoriano bromeo seria bueno un curso de tu auditoria sobre php8 y mysql un crud en MVC Y USANDO OOP y saludos y que tal es estar en nueva zelanda
muy buena, yo lo hago con forEach y Map
Muchas gracias por el video, estaba buscando algo así, Me gustaría saber por qué dejaste de usar vim ?
Estas editando con vs code ?? Exelente que nos des tips de JS con regularidad x youtube Gracias Soy Erwin desce Venezuela Quiero decirte que gracias al entusiasmo que me haz transmitido yo he decidido seguir tus cursos gratuitos de youtube para recetearme y a mis 62 anios de edad recien cumplidos he retomano el camino del desarrollo de software En el anio 1989 egrese de un curso de la fundacion Universidad de Carabobo como Analista Programador lo cual no es un titulo Universitario solo era un curso En Venezuela nunca me contrataron como desarrollador xq los departamentos de informaticas de las empresas estaban profesionalizados o sea solo contrataban a egresados universitarios
Genial.
resulta q estoy trbajando con un Api de estadisticas de dota 2 y elemntos como los items etc , estan dentro de un objeto con propiedades en la cual la clave coincide con el valor de id , posiblemnte usaron ese metodo de reduce o algo similar para crear ese objeto tan grande
no sabia como hacer eso, pero es muy logico es como en SQL precisamente para mejorar busquedas entre tablas no indexadas
y ese hermoso tema cuál es? :o
La hostia, pepita de horo que necesitaba
En el trabajo a veces se presentan ocaciones donde se requiere buscar un usuario no solo por su id, sino por otro atributo. Pars eso se usaría un "composite key" sería genial tener un tutorial de eso.
Saludos!
Muy interesante. Porque no más VIM?
Muy buen vídeo, me gusta muchisimo tu apariencia del VS Code, podrías decirnos que tema y fuente tienes instalado?
Un saludo!
Hay mucha diferencia de rendimiento/velocidad entre usar hashing o binary search?
Habría que que analizar el impactó en memoria y tiempo de GC si es un proyecto productivo
En general, se asume que el precio de una buena tarjeta de memoria RAM es inferior al precio de un procesador, por ende, los desarrolladores prefieren sacrificar memoria que la sobre iteración de los procesos y ciclos, aunque en estos vídeos, uno queda con la falsa idea de que lo que se busca es la optimización en los tiempos de ejecución, cuando a un consumidor estandar ese dato le vale madres, para los proyectos que no sean de ciertos nichos inoficiosos.
Además, que en el vídeo tampoco se menciona nada sobre que es la manera en la cual se está ocupando la información en la RAM, y el modus operandi de la maquinaria en su arquitectura, lo que termina desarrollando mas o menos el mismo proceso que se está haciendo dentro del código con el uso de ciclos, pero de una manera más eficiente a cambio de consumir otro tipo de recursos de la máquina, al desarrollar operaciones matemáticas para obtener la ubicación de la información entre los espacios de la RAM, que en efecto, se van a encontrar considerablemente desperdiciados por la cantidad de posiciones en la ram que se encontrarán ocupadas y desperdiciadas al usar indexaciones que no sean numéricas y consecutivas.
@@1iamigo En JS, como en todos los lenguages con GC, usar memoria no solo es ocupar espacio de memoria sino que también hay que considerar el impacto en el procesamiento. Si no se tiene cuidado, los ciclos de GC pueden meter en algunos casos latencias esporádicas de varias decenas de ms y picos de usos de los procesadores. En un sistema productivo, la acumulación de estos ciclos se puede volver un problema mucho más grande del que muchos piensan. Es de hecho una de las causas más comunes de problemas de optimizacion.
@@javierolazaran7227 Así es, pero reitero, en el vídeo creo que se quedaron corto con respecto a estos temas, tampoco mencionaron nada sobre el orden de las funciones O(n)=n2 > 2n, etc...
Simplemente dicen, "no uses esto, hazlo así porque si, y porque así dio "resultado"."
Con esta manía, vamos a terminar con programadores que dicen ser pragmáticos, que solo van por resultados, pero que solo serán tan precoces como los mismos jefes, y serán igual de engreídos, vacíos y sin fundamentos.
Que buen nivel en algunos comentarios, siempre que veo vídeos así, los comentarios solo son aduladores o trollers, pero aquí hay nivel en tus seguidores, que bien, creo eso debe ser más satisfactorio...
Pero igual sería un problema de memoria en el cliente (si se trata del front) al tener muchos miles de registros, si se requiere buscar algo y se conoce que el número de registros es considerable la mejor estrategia quizás es buscar la manera de que la búsqueda sea a nivel de base de datos y en el servidor
NICE !!!!!!!
Todo depende porque para eso existen los algoritmos de búsqueda que debemos conocer, depende mucho que estes buscando y tambien como esta el array
Vine por recomendacion del master hector de leon, excelente explicacion
No dudo en que sea mucho mas rapido pero creo que tambien debio incluir el tiempo de crear el objeto de users indexado, de igual forma creo que es tremenda entrategia para mejorar el performance.
yo uso pandas con el iloc o loc, así si esta bien?
Hola podrias hacer un tutorial sobre C# por favor
tremendo enredo para usar un hash.