Un error reciente en Windows 11 está generando que un grupo de usuarios vean como su computador pierde 500 GB de almacenamiento por culpa de un archivo del sistema operativo. El fallo no solo impacta el rendimiento de los equipos, sino que puede pasar desapercibido durante meses. Microsoft ya ha reconocido la existencia del problema y ha ofrecido una solución en sus actualizaciones más recientes.
Motivos de edición: * No es necesario copiar literalmente todo el artículo original, para eso se pone la fuente. Normalmente se pone el primer párrafo * Tampoco las imágenes de stock/genéricas/hechas con IA que a veces tienen dentro los artículos * Ni los textos al pié de esas imágenes * Y mucho menos los enlaces internos del propio medio que apuntan a otro artículo del propio medio (autospam) * Tampoco el título clickbaiter del vídeo de Youtube ("¡Mira Tu PC Ya! Borra este archivo oculto de Windows que roba hasta 500GB") * Y no es necesario poner por triplicado (en el enlace del medio, en el vídeo y en este mismo post) la solución del fallo de Windows * Tras revisar el vídeo, a pesar de que en el título se usa urgencia y alarmismo, dentro del vídeo se indica que no se debe borrar el fichero. También confunde un update opcional de drivers AMD (que no tiene KB) con el update que arreglaría el fallo (KB5095093). El vídeo induce a error, por lo que se descarta * En las notícias no se añade opinión personal. Sino no serían notícias, serían artículos de opinión
No sé a qué tipo de cheat "simple" se referirán ustedes. Es posible que desarrollar cheats basados en guías prediseñadas para videojuegos masivamente explotados (ej. Counter-Strike), donde te desglosan el proceso y el procedimiento paso a paso, pueda considerarse una tarea relativamente sencilla. Sin embargo, y dejando a un lado el diseño de la interfaz gráfica y la lógica detrás de los controladores de eventos de los controles y también la metodología a aplicar para inyectar el cheat al proceso, yo me voy a referir de forma exclusiva a la labor de ingeniería inversa pura que constituyen el descubrimiento de offsets y el desarrollo de las instrucciones del núcleo de un cheat:
Al desarrollar las instrucciones de inyección para mis propios cheats (como muestro aquí, aquí y aquí), la realidad es muy distinta: El procedimiento rutinario exige escanear, contrastar y aislar valores dinámicos en la memoria volátil del proceso, a veces inyectar un depurador (VEH) para establecer breakpoints de hardware/software e identificar qué rutinas acceden a cada dirección, y, por supuesto, aplicar nociones de lenguaje ensamblador (las instrucciones que constituyen el cheat) para alterar el flujo original del binario.
A esto hay que sumarle el posible análisis de estructuras complejas en memoria, como la generación de pointermaps para resolver cadenas de punteros hasta la base estática del módulo. Lograr todo esto partiendo absolutamente de cero para un programador es prácticamente inviable si no cuentas o bien con una suite especializada 'todo en uno' como Cheat Engine, o con mucha experiencia propia y plantillas prediseñadas. Sin ella, el primer paso por pura necesidad habría sido desarrollar un framework propio en un lenguaje de programación apto para invocar las API nativas de Windows (OpenProcess, ReadProcessMemory, WriteProcessMemory, etc) solo para poder leer y escribir un mísero byte en el proceso del videojuego.
Además, y dependiendo de la tecnología del videojuego, he tenido que reconstruir los metadatos de Unity con el fork de il2cppdumper, analizar el código intermedio de binarios .NET con dnSpyEx, o inspeccionar archivos de depuración PDB con PDBRipper. Todo esto dista un mundo de ser "fácil" para un programador común y corriente sin ningún tipo de experiencia previa en el reversing de videojuegos o simplemente sin experiencia en el análisis de binarios y estructuras de datos relacionadas. Y ojo, que yo tampoco soy un experto en ingeniería inversa aplicada a videojuegos, solo sé lo justo y necesario para poder hacer los cheats que hice sacando esos pequeños proyectos adelante.
Todos estos procedimientos, algunos estrictamente necesarios, otros opcionales, en ningún caso puede considerarse como ejercicios simples para un "TOP 10 de programas fáciles para aprender a programar".
@Tachikomaia, por todo lo que acabo de explicar, no deberías seguir pensando en esto de los cheats como algo "simple", por que no lo es. Quítatelo de la cabeza.
Voy a decirte algo para argumentarlo mejor, y sin ánimo de ofenderte, pero cualquiera que lea ciertas consultas y respuestas que has publicado en el foro puede darse cuenta que sueles encontrar trabas o tropiezos con problemas que para otros programadores serían relativamente muy sencillos de resolver, por lo que estos temas de "crear un cheat" a ti te resultarían especialmente más complicado de forma general, puedes creerme. Y no es que seas más tonto que los demás, sino que simplemente todavía no has adquirido suficiente experiencia general en programación como para poder profundizar en temas avanzados que impliquen el análisis y manipulación del espacio de direcciones de memoria de un proceso.
Y hablamos en ocasiones de cheats tan "simples" como munición o vida infinita.
Además, un emulador de videojuegos, que sé que eso es lo que a ti más te interesaría, debo decirte que implica una capa de "aislamiento" de la memoria del video juego, y, por ende, una segunda capa de complejidad durante el procedimiento de análisis y manipulación de memoria, a menos que el emulador disponga de funcionalidades avanzadas integradas para depurar, y analizar directamente la memoria del video juego. En otros casos puede haber herramientas externas especializadas (ej. Dolphin Memory Engine para el emulador Dolphin de Wii y GameCube), o guías de como se debe utilizar exactamente Cheat Engine para cierto emulador, como por ejemplo esta guía para el emulador PPSSPP de Playstation Portable.
Pero si realmente quieres probar primero con algún emulador para intentar hacerlo más sencillo, lógicamente ha de ser emulador de NES, Game Boy o de roms que ocupen menor tamaño en memoria, por esa sencilla razón, a menor tamaño más fácil.
Aunque también te digo, hoy en día sería una tontería sin sentido ponerse a hacer cheats de roms de Nintendo, en especial de NES, cuando ya hay recopilaciones de los mejores cheats para casi todas las roms existentes, y son compatibles con diversos emuladores, como por ejemplo este. También hay recopilaciones de cheats para los emuladores de Nintendo 64, Game Boy / GB Color / GB Advanced, GameCube y Wii/Wii-U. Y para los emuladores de las consolas de Sony también, claro, y para los emuladores de arcade tipo M.A.M.E, con miles y miles de cheats en un solo paquete.
Estadísticamente hablando, cuanto más moderno sea el videojuego (para PC), más complejo debería ser el desarrollo de un cheat. Dependiendo de la tecnología que utilice, entre otras cosas, pero por regla general será así.
Si hablamos de videojuegos antiguos de hace 15 o 20 años, o juegos de MS-DOS pues (estadísticamente hablando también) el procedimiento será mucho más simple, ya que la estructura de memoria del proceso es o debería ser mucho menos compleja. Sin ir más lejos, he creado cheats para el videojuego Driver, lanzado en el año 2000, y al no usar punteros es cuestión de buscar y encontrar direcciones estáticas:
Eso es algo relativamente muy sencillo de hacer, siempre y cuando el programador disponga de suficiente experiencia, o el usuario disponga de las herramientas adecuadas, como en este caso Cheat Engine. Pero en cualquier caso, crear un cheat es algo que requiere un mínimo de perspicacia...
¿Por qué? Sencillamente porque si pones a alguien sin experiencia ni intuición a rastrear valores en la memoria del proceso sin saber qué busca ni dónde mirar, perderá una cantidad ingente de tiempo. Y si por puro azar llega a dar con un valor clave, es posible que no sepa ni identificar lo que tiene delante y lo acabe descartando por puro desconocimiento.
Por todo lo que he explicado y opinado en este post, insisto de nuevo: personalmente considero que crear un cheat no puede catalogarse como un ejercicio simple para un "TOP 10 de programas fáciles para aprender a programar".
No hay complicaciones con eso, de verdad. Instalar Python es tan sencillo como descargar el instalador oficial de su web y ejecutarlo. Lo único que requiere un pelín más de atención viene después cuando te pones a configurar el entorno de Python para empezar a trabajar.
EDITO: De todas formas, y para una instalación desatendida y sin menos complicaciones todavía, siempre puedes recurrir a la instalación de la Configuración para desarrolladores de Windows (Windows Developer Config) oficial de Microsoft:
- No viene con algo donde puedas dibujar o insertar dibujos normales, es tipo DOS, probablemente haya que buscar, y puede que no sea fácil saber cual es
Lo que buscas se denomina "Visual GUI builder" o diseñador de interfaces gráficas y suele formar parte de un buen IDE (Integrated Development Environment, o Entorno de Desarrollo Integrado).
Primero se elige un framework con el que trabajar (lo que incluye las librerías especializadas que te permiten construir una interfaz gráfica) y luego buscas un diseñador de interfaces gráficas que soporte ese framework específico...
- No permite concatenar un texto y un número, tienes que convertir el número en texto.
Claro que lo permite, mediante la interpolación de strings:
Código
age: int=25
print(f"Age: {age}")
Busca sobre "F-Strings" en Python para más ejemplos o información.
Es de facto una conversión de tipos, pero posiblemente te referías a concatenar con "+" y eso no es necesario; las cosas se pueden simplificar mediante la interpolación.
- Hace años cuando intenté que un programa genere un archivo, no pude.
Pero el culpable no fue el lenguaje de programación, sino muy posiblemente un tropiezo técnico por parte del humano.
Escribir el código para crear un archivo es muy simple, pero si el entorno no está bien configurado (por ejemplo, si no hay permisos de escritura en esa carpeta), o si el archivo está en uso por otro programa, entonces todo se va a la *****.
- Aún tengo problemas para hacer que el programa más simple del mundo funcione, por problemas del formato, que no entiendo porque si lo grabo como py entonces el formato debería ajustarse a py, pero parece que hay un py UTF8 y otros tipos de py.
Se te explicó el motivo del problema y la solución. De hecho, se te ofrecieron varias soluciones.
Todo es cuestión de ir aprendiendo. Usar una codificación de texto incorrecta o errores parecidos es algo que TODOS hemos sufrido al aprender. No dejes que algo así te desanime con Python.
si al mostrar código o un ejemplo es una página que tienes que hacer un curso para poder entender qué es lo que muestra y ver el código, algo está mal en eso.
Pero no me eches la culpa a mi, ¿te das cuenta que estás publicando constantemente en una sección de programación?; Lo lógico por mi parte cuando te respondí era asumir que estarías familiarizado con una de las plataformas que la mayoría de los programadores dominan en mayor o en menor medida, pero que todos los programadores hoy en día conocen, como es GitHub.
Imaginate que en el foro en vez de poner códigos se pusieran archivos para descargar, junto con unos que tienes que hacer un curso para entender qué son ¿no te parece absurdamente burocrático?
Estás mezclando las cosas, cuando cada herramienta tiene su función. El foro es ideal para debatir, responder y darte "códigos" de forma rápida, mientras que GitHub es el espacio diseñado específicamente para que los programadores puedan subir, revisar y descargar código fuente de forma limpia y ordenada, y los usuarios puedan navegar por los archivos del código fuente de forma estructurada. No es burocracia, sino organización.
Si la página esa no es capáz de mostrar códigos de forma normal, cómoda para el usuario
Solo tienes que ubicar en el repositorio el archivo de código fuente que quieras analizar, y hacer click en él para ver su contenido.
EDITO: De todas formas, comprendo que al no estar familiarizado con un sitio web y su estructura de organización no sepas a dónde ir para encontrar lo que buscas, pero es cuestión de práctica. Yo casi nunca recuerdo dónde está cada cosa en Bitbucket (otro repositorio de códigos tipo GitHub) por lo poco que lo uso, y me pierdo. A veces me he perdido también en la Visual Studio Market Place (https://marketplace.visualstudio.com/) para gestionar mis publicaciones y en la galería de NuGet (https://nuget.org) también.
La solución parece simple, no comprarles hasta que vuelvan a lo que quieres
La solución siempre parece simple sobre el papel, pero en la práctica todo suele depender de lo que decida hacer la masa aborregada, que por lo general suele elegir exactamente la solución que menos le beneficia...
Me explico, la civilización humana está compuesta mayoritariamente por una masa de gente estúpida. Es un hecho casi empírico, una realidad demostrable y palpable. Y, al final, esa masa mayoritaria, con escaso sentido de criterio y de objetividad (y ya ni hablemos de conciencia de consumidor), siempre terminará pasando por el aro.
Si una masa conformista y complaciente traga con el cambio y sigue comprando el producto, la empresa no sufre penalización económica ni castigo alguno, por ende, no van a rectificar sino más bien todo lo contrario.
Y viendo los antecedentes de lo que suele elegir la masa mayoritaria, no hay que ser ningún genio para darse cuenta de que estamos presenciando el verdadero final del formato físico, cosa que ya estaba tambaleándose en la cuerda floja durante muchos años, pero ahora se le están dando las estocadas finales.
Si necesitas realizar esa pregunta, entonces está claro que responderte un simple "sí" no te va a servir de mucha ayuda, así que activo el modo "RESPUESTA EXTENSA":
Flash / ActionScript es tecnología del pasado sin soporte ni futuro, y las IA actuales solo te harán perder el tiempo, marearte y causarte problemas debido a sus frecuentes alucinaciones.
Si de verdad te apetece programar, ya sea por hobby o por lo que sea, no sigas perdiendo el tiempo con cosas del pasado, tíralas a la basura y empieza a asimilar conceptos reales con un lenguaje actual como Python. Empieza por dominar los fundamentos e introducirte a fondo en la sintaxis y semántica del lenguaje, hasta que como mínimo entiendas el significado y propósito del ecosistema de archivos como .py, .pyc, .pyd, .pyw y .pyi.
¿Que lo tuyo es programar video juegos? Pues mi respuesta sigue siendo la misma: tira a la basura Flash / ActionScript. Aquí tienes ejemplos hechos en Python para aburrir:
Desde un "Contra" hasta un "Zelda" RPG. Si accedes a cualquier repositorio la mayoría tendrán capturas de pantalla o GIFs animados para que te hagas una idea de lo que se puede llegar a hacer con Python. Y tutoriales no te van a faltar en Internet, está literalmente plagado de ejemplos en Python, y eso también es bueno a la hora de realizar consultas a una IAs... en comparación con ActionScript.
O directamente te lanzas al vacío y das el gran salto al lenguaje C# (C-Sharp) usando la suite de Unity para el desarrollo de video juegos en plan "pro". Pero eso ya implicaría aprender no solo un lenguaje de programación desde cero, sino además un motor de video juegos gigantesco. No creo que sea recomendable en tu caso en específico.
Pregúntale a la IA que le parece esta recomendación que acabo de hacerte. Estoy convencido que si la IA "te aprecia" también te dirá que empieces YA con Python y te olvides del ActionScript.
Pero bueno, esto solo es una recomendación general suponiendo que quieras ampliar conocimientos y habilidades de programación. Pero como es evidente yo no puedo saber a lo que tú aspiras, ni si te conformas con ActionScript y no quieres nada más por que no necesitas programar cosas más complejas.
Tampoco sé qué tipo de archivos son .gitignore y README.md Los readme suelen ser en txt, doc, pdf...
".gitignore" es básicamente una "lista negra". Es un archivo de texto plano donde el autor del proyecto define reglas para archivos y carpetas que quiere que Git (el sistema de control de versiones del código fuente) ignore completamente. Hay muchas plantillas por Internet para diferentes tipos de lenguajes de programación, incluyendo para Python.
"md" es la extensión para archivos Markdown, el formato de texto plano / lenguaje de markup estandarizado para documentar repositorios en GitHub. Un "README.md" es el archivo principal que la plataforma renderiza para describir el proyecto en la página principal del repositorio. No lo vas a ver con otra extensión de archivo...
Tú a lo que te refieres es incluir archivos de texto plano como "Léeme.txt" o "Readme.pdf" cuando se distribuye software al usuario final, pero eso no sustituye el uso de Markdown para documentar repositorios / código fuente.
De todas formas, cualquier editor de texto hoy en día es capaz de interpretar y hasta renderizar formato Markdown. Sin ir más lejos, el Bloc de Notas de Windows 11 lo soporta de forma nativa y todo lo que escribes y los botoncitos para poner palabras en negrita y cursiva y etc generan formato Markdown en segundo plano. Eso para que te hagas una idea de lo común y adoptado que está el formato Markdown aunque pienses lo contrario.
EDITO: se me pasó por alto mencionarte que hay aplicaciones web, como la siguiente, para construir tu documento Markdown:
pero si lo piensas nunca lo fueron, son código metido en una placa o un disco o no sé qué (...) algo que funcionara dejando caer bolas o cosas así tendría más duda de decir que no es físico
...¿Qué?.
Se llama formato físico porque un cartucho o un CD es algo real que puedes tener en la mano. Te pertenece, eres su propietario y nadie te lo puede quitar por las buenas. El soporte y los circuitos impresos o "placa" que contienen ese código son materia tangible.
El formato digital es solo una licencia de uso. No posees nada tangible, dependes de servidores externos y de la voluntad de una compañía que en cualquier momento puede borrar el juego (como ya ha sucedido en tantas ocasiones), cerrar la tienda o quitarte el acceso. ¡Y no te van a devolver el dinero de aquello digital que compraste y te arrebataron!.
Confundir la naturaleza del software con el soporte que lo almacena no tiene ningún sentido.
Si por ejemplo mañana Sony desaparece, todas tus compras digitales en la PlayStation Store desaparecerán también, perdiendo por completo el acceso a todos los juegos y películas que compraste (y sin obtener ningún reembolso, insisto). La diferencia con el formato físico es evidente, porque tus discos y cartuchos seguirán estando en tu estantería, listos para funcionar en tu consola sin depender de que una empresa exista o no, o decida eliminar títulos o no...
"Sony eliminará más de 500 películas de PlayStation Store"
lo de lujuria supongo que es un gran error de traducción
Jeje, se nota que no la has leído ni visto. "Un Mundo Feliz" es lujuría y deshinibición en estado puro, una especie de Sodoma y Gomorra moderna y distópica donde el sexo se fomenta desde la infancia, y el placer sexual forma parte de los mecanismos con los que el Estado totalitario mantiene a la población satisfecha y dócil, de una forma tan sutil y perfecta que el Estado no necesita recurrir al terror, a la policía secreta ni a la violencia para someter a la población.
Por eso, no creo que sea un error de traducción...
Yo te recomiendo esta serie, doblada al español de España e imagino que también al hispanoamericano:
La serie fue cancelada tras a primera temporada, pero aun así personalmente me gustó mucho.
En torno a tu pergunta, hay dos películas. Bueno, una es considerada una miniserie, pero es una película (como sucede con la película/miniserie del payaso "It"). Ambas dobladas al español de España según las evidencias que encontré. El problema es que ambas son películas emitidas por TV, es decir, nunca llegaron a comercializarse en España, así que encontrar los doblajes es muy complicado (puede que imposible)...
La peli de 1980 ("miniserie" de la BBC) se emitió en la televisión pública española durante aquella época:
La puedes encontrar en VOSE en el emule, no cuesta nada y es gratis.
Si te conformas con calidad chusca de Youtube, pues aquí la tienes también en VOSE:
La peli de 1998, teóricamente se supone que se emitió en el canal Calle 13 durante los años 2000 en la TV española (fue un canal muy conocido de nuestra infancia). Pero ni rastro del doblaje en español de España, sin embargo, también es fácil de encontrar en VOSE, tanto en el emule como en Telegram.
En general, Telegram es un gran aliado para encontrar todo tipo de películas estrenos y antiguas. Hay muchísimos canales y grupos en todos los idiomas... como por ejemplo Comunidad Castellana, uno de los más grandes, y el grupo de @Aokromes que está relacionado con material de cierto sitio web de torrents y en ese grupo de Telegram hay disponible todo el material cinematográfico que puedas imaginar. Ambos grupos para películas sobre todo.
También están los foros especializados como "DescargasDD" para descargas directas, y trackers privados de torrents como "HD-Olimpo" (HDO) que por cierto es el más grande de España y el que más contenido tiene de entre todos los trackers privados de habla hispana sin ninguna duda, pero en fin, ya dejo de mencionar sitios que tampoco es plan de hacer spam.
Me he tirado todo este domingo desde por la mañana hasta las cinco de la tarde investigando la forma de identificar el origen de los atajos del teclado en la versión UWP de Notepad en Windows 11, pero no he encontrado la forma. Me rindo.
He utilizado una herramienta command-line poco o nada conocida por nombre PriExplorer.exe para analizar los archivos *.pri: https://github.com/chausner/PriTools Además, también sirve analizar los archivos *.xbf, pero solo encontré cadenas de texto relacionadas, nada que me parezca útil ni relevante.
He buscado en los archivos *.mui que el Notepad mantiene abiertos, pero tampoco encontré nada relevante.
Con el archivo "AppxBundleManifest.xml" dentro del directorio del paquete de Notepad (en "WindowsApps") intenté un par de cosas eliminando la referencia al idioma "es-ES", pero no surtió efecto.
Con el editor hexadecimal encontré referencias a funciones win32 con nombres tipo "CreateAcceleratorTableW" y "DestroyAcceleratorTable" en el archivo Notepad.exe, y también referencias que parecen estar relacionas con la carga del idioma y el manejo de los aceleradores del teclado como por ejemplo: "AppLanguageResourceLoader", "ShortcutType" y "AccessKeyType" en el archivo NotepadXamlUI.dll, pero no sé que hacer con todo esto....
Estoy convencido que con conocimientos de desensamblador se podría averiguar algo en concreto en relación con esos dos archivos tal vez añadiendo un breakpoint cuando el programa realiza la llamada la función "CreateAcceleratorTableW" y averiguar el origen de los valores que se le pasan a dicha función (datos de la estructura "ACCEL"), pero yo no tengo los suficientes conocimientos como para rastrear esas cosas en un desensamblador.
En fin, eso sería todo.
Dejo por aquí escritas dos claves de registro relacionadas:
Existe una alternativa para usar los atajos del teclado "inglés" en Notepad moderno de Windows 11, la solución consiste directamente en eliminar el paquete relacionado con el idioma español desde una terminal de Powershell:
Esto permite usar CTRL+A para seleccionar todo y etc, pero tiene el obvio inconveniente de volver toda la interfaz de usuario del Notepad al idioma inglés.
Algo es algo, supongo.
Qué rabia no haberlo conseguido esta vez por la vía más directa y menos destructiva.
Un saludo.
EDITO: Por cierto, también estuve probando este "Legacy Notepad" en Windows 11:
No revisé el código fuente, solo lo compilé y lo pasé por Virustotal, todo OK.
Tal vez no tiene mucho sentido usarlo teniendo acceso al notepad clásico en el propio Windows 11, pero en Windows 11 primero hay que desactivar un alias llamado "Bloc de Notas" en la configuración del sistema, en la sección de "Configuración avanzada de aplicaciones" (o un nombre similar a eso), por que aunque escribas la ruta exacta del notepad clásico o aunque abras la carpeta C:\Windows\System32 y hagas doble click sobre el notepad clásico siempre se ejecuta el moderno si no desactivas el alias. Cómo complican las cosas los de Microsoft.
Hola. Solo quiero añadir que no basta con especificar la codificación en el código fuente, sino que además la codificación del archivo debe coincidir con la que se haya especificado.
"coding: utf-8" no convierte la codificación del archivo fuente. Lo único que hace es indicarle al intérprete de Python con qué codificación debe interpretar los bytes del archivo fuente.
Ya te han indicado cual es la solución más coherente con la codificación por defecto que utiliza Python. Sin embargo, y como alternativa aislada para tu caso, puedes especificar: "# coding: windows-1252" - eso lo escribes siempre la primera línea arriba del todo ya que seguramente en tu entorno hispanohablante por algún motivo estés creando los archivos con esa codificación, y de ahí viene el conflicto. Hazlo solo en caso de que prefieras evitar guardar el archivo con codificación UTF-8 como te han dicho. Aunque esto no sería una buena práctica hacerlo.
Por cierto, en el código que has mostrado estás realizando cientos y cientos de operaciones de escritura (I/O) sobre el archivo de texto cada vez que el búfer interno por defecto de Python (de muy pocos kilobytes, 8 me parece) se acumula y se vacía (flush). 3,61 MB / 8 KB = aprox. 451 de escrituras en el archivo de texto.
Lo suyo es utilizar un búfer con tamaño arbitrario en memoria para reducir drásticamente la cantidad de syscalls de escritura sobre el archivo físico:
Asegúrate de utilizar el parámetro para especificar un tamaño de búfer arbitrario:
En este ejemplo, usando 100 MB como búfer de memoria, directamente te aseguras una única escritura sobre el archivo, ya que el archivo resultante con todas las combinatorias de palabras no llega ni a los 4 MB de tamaño. ¿Es un overkill? No si piensas escalar tu código actual para generar longitudes más grandes.
Aparte, la anidación de bucles 'for' también es mejorable y es un punto crítico en tu código que merma mucho la velocidad de ejecución. Con el código actual no vas a notar diferencia, pero con longitudes más grandes si lo notarías y de forma muy exponencial con periodos de tiempo extremadamente largos para completar la ejecución del programa ya que esos 'for' suponen varios problemas que añaden overhead en Python.
Lo ideal es que utilices itertools.product (implementado en el lenguaje 'C'):
with multiprocessing.Pool(processes=cores)as pool:
for chunks in pool.imap(worker, CHARSET):
forchunkin chunks:
f.write(chunk)
elapsed =time.perf_counter() - start
print(f"Tiempo total: {format_elapsed(elapsed)}")
if __name__ =="__main__":
main()
input("Press Enter to exit...")
Los resultados son claros:
Longitud = 4, tu enfoque actual: ~800 ms Longitud = 4, optimización básica itertools.product: ~350 ms Longitud = 4, optimización completa itertools.product multi-core: ~240 ms
(aquí es donde la cosa se pone seria)
Longitud = 5, tu enfoque actual (bucles anidados y adaptados para esta longitud): ~19 segundos. Longitud = 5, optimización básica itertools.product: ~9 segundos. Longitud = 5, optimización completa itertools.product multi-core: ~3 segundos.
Longitud = 6, tu enfoque actual (bucles anidados y adaptados para esta longitud): SIN MEDIR (estima de 30 minutos para arriba}. Longitud = 6, optimización básica itertools.product: ~14 minutos. Longitud = 6, optimización completa itertools.product multi-core: ~2 minutos.
Mostrar Mensajes
