Yo quise mencionar lo mismo, pero me arrepentí.
Y es que cada cabeza es mundo, por ejemplo: en mi opinión, cada aplicación que se carga en el sistema representa un consumo de RAM, procesador y disco.
Y como bien dice
@Ferdinando12, existen muchos scripts al igual que comandos para el CMD que hacen lo mismo o mejor que esas aplicaciones de optimización y limpieza, que de hecho yo considero completamente inútiles y sí una sobre carga, aparte de que son de pago.
A mí siempre me ha gustado más optimizar el sistema a mano y tengo una carpeta repleta de asuntos relacionados a esto.
Así que cuando requiero algo, voy y busco, lo ejecuto y asunto resuelto.
Yo me inicié en esto de la computación por allá del MSDOS 6.0, así que lo del Windows y sus "trucos" son comunes.
Posteriormente llegó Windows NT que dejaría atrás a los Win 16 y se empezaba a abrir otro mundo.
Fue algo brusco el cambio pero maravilloso a la a vez, estábamos conociendo otras cosas del sistema.
Los FAT cambiaron y con ello se ingresaba a otro mundo.
Dado este hecho conocí MAMS32, un compilador de 32 bits que fue como mi más preciada aplicación.
Con este compilador aprendí muchas cosas sobre las librerías de Windows, sus API.
Ahora, con la llegada de Windows 11, prácticamente no hay nada que hacer en lo que respecta al performance del sistema.
Lo hace solo, aparte de que mantiene aplicaciones en un modo de eficiencia al que yo le llamo "Green Mode" y esto es porque los procesos de alto consumo son marcados con unas hojitas verdes.
¿Qué se puede hacer con un sistema que ya tiene contemplada su eficiencia?
Pues relativamente nada en lo que respecta a aplicaciones, estas son cargadas por threads independientes, y son enumeradas.
Así que lo cuelgues en Windows 11 ya no existen, si un proceso se cuelga lo manda a segundo plano hasta que responda.
Si no responde se notifica y se puede cerrar o seguir esperando, vía notificación.
Esto para mí fue algo nuevo a nivel de programador porque estaba acostumbrado a que cuando compilaba y si el proceso "mi aplicación" se llegaba a congelar por errores o exceso en consumo de recursos, lo que me quedaba hacer era recurrir al administrador de tareas y terminar al compilador.
Ahora ya no es así, ahora se puede terminar la aplicación desde el botón "Stop" y también desde el administrador de tareas como una aplicación independiente, sin que esto afecte o termine la ejecución del compilador, simplemente el compilador determina que la aplicación terminó y puedes seguir en donde estabas.
Antes esto no era posible, si tu aplicación se congelaba era un hecho que tendrías que terminar al compilador.
Por suerte, Visual Studio .Net siempre guarda, crea y ejecuta lo último programado cuando se compila la aplicación.
En fin, a mi punto de vista, no hay nada mejor que mantener un sistema libre de aplicaciones que se carguen al inicio y que no son primordiales.
Lo siento por esas personas que usan AutoCAD y programas similares que si no cargan sus aplicaciones de comprobación de licencia, no funcionan.
Un tache para estos programadores, ya que existen métodos mejores sin necesidad de previa carga para comprobar status y licencias.
.
