Foro de elhacker.net

 Hola,

Me he dado cuenta de que cuando un programa tarda mucho en un ciclo (haciendo algo util o no) Windows reduce la velocidad de ejecucion del programa (imagino que para evitar denegaciones del servicio). Quisiera saber como hacer excepciones de esto para algunos programas ya que se esta tardando literalmente cuarenta y un minutos en cargar veinte megabytes de un archivo  :huh: lo cual me parece descomunalmente demasiado. Me da igual que se realentice el sistema.

Gracias, un saludo.

Es 'raro' eso de que cargue 20 mb. de tamaño de un fichero en memoria en más de 40 minutos, debería ser inmediato (hoy día 20 mb. es poca cosa).

Puede suceder una de las siguientes cosas (así, sin más detalles).
- No queda memoria libre suficiente, o está muy fragmentada. Tu mismo podrás comprobar si es el caso y de ser necesario activa la escritura de RAM a disco (si no se cambió por defecto el S.O. suele ootorgarle algo así como un mínimo de 512Mb.). Por su parte cuando hay mucha memoria en el sistema, e spreferible desactivarlo, porque su uso ralentiza al S.O. que a pesar de la gran cantidad de mmemoria en el equipo, pueda empeñarse en tirar de páginas a disco.
Otra opción más sencilla si se entiende que ya está configurado adecuadamente, es cerrar aplicaciones que no se precisan, para liberar memoria.

- Que haya algún sector dañado en el disco duro. Puede abortar la operación o puede intentr 'rumiar' intentando leer el contenido y avanzar muy lentamente.
en tal caso o ante la duda conviene hacer un chequeo dle disco completo (buscando por secotres dañados y que queden marcados como tal y que recupere los que no estén dañados).

- Adicionalmente la presencia de algún virus podría tener suspendido algún proceso... o manipulado algún driver.

- Algo mucho menos frecuente  (depende del S.O. de tu equipo), es que dado ciertas fallas (generalmente por daños en disco), es que le haya cambiado el modo de tranferencia (de DMA a PIO). Esto podía ser frencuente a finales de los 90 y comienzos de siglo, pero no he escuchado desde entonces que esto siga sucediendo hoy (por eso digo que depende dle S.O. con el que estés haciendo tus pruebas).

Y sin más detalles no se me courren más razones...

Gracias por responder, Serapis.

Ya se que es raro.

Perdon por no plantear la duda tan exactamente pero no es que se tarde en mover la informacion del disco a la memoria. Sere mas preciso respecto a la estructura del programa:

El programa carga el archivo completo en memoria (20 mb) y en esto se tarda unos 700 ms.

En lo que se demora es en lo siguiente:

Una vez el contenido del archivo en memoria, que es simplemente un conjunto de estructuras anidadas pero eso da igual... El problema es que yo estoy midiendo constantemente el rendimiento del programa, que supongase que es algo asi:

for(i=0;i<tamanyo del archivo;i++)
{
 
fread((struct __loquesea *) &estructura, sizeof(__loquesea), 1, hArchivo);
 
//...
}
 

Como decia, estoy midiento el rendimineto del programa y resulta que los primeros 2 segundos el programa carga mas de cien mil de estas estructuras, luego en los siguientes dos segundos carga cincuenta mil, luego veinte mil... hasta llegar a unas diez mil estructuras por segundo.

Las estructuras que necesito cargar son 11.352.960.000 en total, y podras deducir que cuando el programa falla estoy horas depurandolo lo cual me parece una tonteria...

El punto: No entiendo por que el programa carga muchas por segundo al principio y a medida que avanza la ejecucion del programa Windows ejecuta el programa mas lentamente, como previniendo que un bucle infinito inutil este denegando el servicio o evitando la ejecucion a otros programas. No entiendo por que hace esto

Si estás leyendo 100.000 estructuras en principio, a pocos bytes que tenga esa estructura, habrás consumido los 20Mb. en un parpadeo. Entonces me pregunto si estás obteniendo y consultando el retorno de fread, si no devuelve la misma cantidad de bytes que se intenta leer, o se llegó al final de fichero o hay un error.

Cuando hay un error se genera un reporte, como estás en un bucle y no lo tratas (es un a dedución a falta de un código más explícito), básicamente estás generando reportes de error, constantemente que por sí mismo podrían explicar la caída del rendimiento.

Si no es esto, deberías poner aunque sea un ejemplo práctico que reproduzca el error, no necesariamente todo tu código, basta simplificado para que pueda reproducirs el error e investigarlo un poco más a fondo.

No hay suficiente informacion como para que lo adivine pero deberias minimamente comprobar el uso de CPU y RAM en el Administrador de tareas de Windows (y el Monitor de recursos tampoco vendria mal) para detectar el cuello de botella. Si tu programa tiene un solo hilo lo mas normal es que no pueda usar mas que un procesador/nucleo del total y dudo que cambie porcentaje de uso de CPU con el tiempo.

Esta bien. Esta es la funcion en la que el programa demora los 41 minutos ejecutando:

int LoadNextQuoteIntoQuotesmem (struct __csvheader *csvheader, struct __quotesmem *bQuotesmem)
{
    char c;
    int i, k;
 
    char szBuffer[MTFMT_MEM_QUOTEMAX];
 
    //fsetpos(csvheader->hFile, &(csvheader->fpos));
 
    for (i=0;i<MTFMT_CSV_QUOTEN;i++)
    {
        c=0;
        for(k=0;c!=','&&c!='\r'&&c!='\n';k++)
        {
            c=csvheader->bBuffer[csvheader->fpos];
            csvheader->fpos++;
            if(c==0/*EOF*/)
            {
                return MTERR_CSV_EOF;
            }
            szBuffer[k]=c;
        }
 
        szBuffer[k-1]=0;
 
        switch(i)
        {
        case 0:
 
            strcpy (bQuotesmem->data0, szBuffer);
            break;
 
        case 1:
 
            strcpy (bQuotesmem->data1, szBuffer);
            break;
 
        case 2:
 
 
            bQuotesmem->data2=atof(szBuffer);
            break;
 
        case 3:
 
            bQuotesmem->data3=atof(szBuffer);
            break;
 
        case 4:
 
            bQuotesmem->data4=atof(szBuffer);
            break;
 
        case 5:
 
            bQuotesmem->data5=atof(szBuffer);
            break;
 
        case 6:
 
            bQuotesmem->data6=atof(szBuffer);
            break;
        }
    }
 
    if (i<MTFMT_CSV_QUOTEN)
    {
        return MTERR_QUOTEN_DOESNT_MATCH;
    }
 
    //fgetpos(csvheader->hFile, &(csvheader->fpos));
 
    return 0;
}
 
 

Por lo que podran deducir el archivo en cuestion es un CSV con nueve columnas (Y en este caso el archivo tiene 11.352.960.000 filas).

La estructura __quotesmem es simplemente una estructura en RAM en la que ordeno los datos para poder manejarlos luego.

Cabe mencionar que:

La estructura es una lista enlazada, por lo que por cada fila nueva llama a malloc. ¿Es malloc una funcion lenta? Porque de ser asi puede estar ahi el problema la verdad...

La funcion es llamada cuantas veces sea necesario hasta que retorne final del archivo MTERR_CSV_EOF.

Importante tomar en cuenta: Para cuando se llama esta funcion el contenido del archivo ya esta en memoria RAM. Se encuentra todo en csvheader->bBuffer.

Nota: Hay cadenas comentadas porque solia usar esta funcion accediendo a cada caracter individual del archivo, lo cual.... jajajaja... eso si se tardaba un buen rato. Cuarenta minutos es muy poco en comparacion. Aun asi me parece mejorable por eso hago este tema, porque ni siquiera creo que este calculando algo innecesariamente aqui. Insisto en que tal vez sean las tantas llamadas a malloc...

Eternal Idol, el programa usa siempre el mismo porcentaje de la CPU. Lo que cambia es el acceso a memoria. Si pongo en el codigo un printf("%d/%d\r", csvheader->fpos, csvheader->fsize); Puedo ver como los primeros cientos de miles de bytes se cargan rapidamente, y luego va disminuyendo la velocidad de carga. El porcentaje de uso del procesador esta siempre igual (en torno a un 15%). Lo que va disminuyendo es la velocidad de acceso a la memoria RAM.

Otra cosa importante que olvide mencionar es que se que el rendimiento podria ser mejorado mucho porque puedo abrir cuatro instancias del mismo, al mismo tiempo y los cuatro se tardan los mismos 41 minutos ejecutandose.

¿Ese archivo entonces pesa por lo menos unos 80GiB? Tienes 10.57 "gibifilas"... Si cada fila solo tuviera un byte, estarías hablando de 10GiB. Ese archivo debe ser un monstruo para que tengas tantas filas...

Yo creo que a finales de cuenta, el comportamiento en el cual se reduce el rendimiento a medida que sigue progresando se puede explicar por una cache. Puede ser quizás la cache del sistema operativo, cache de CPU (L1, L2, L3) o cache del dispositivo de almacenamiento (o de varios de estas).

De los cuales, solo puedo ofrecer una explicación para los SSDs (aunque me imagino que esto también vale para HDDs híbridos). Los SSDs pueden hacer uso de memoria para conservar un mapa de la información almacenada, así acelerando la respuesta del SSD. Llega un punto donde la memoria se satura y aquí el rendimiento empieza a degradar. Los SSDs PCIe gen 4 pueden por ejemplo alcanzar lecturas desde hasta 7.7GB/s... por un periodo de tiempo... En promedio puedes obtener alrededor de 1.5GB/s si mal no recuerdo...


¿Revisaste que no tuvieras un hilo/cpu al tope?

Necesitas poder verlo así:

(https://i.imgur.com/DznuI97.png)

Me equivoque de calculo  ;D

En total son 31.536.000 estructuras mas o menos...

Adjunto capturas del rendimiento:

(https://i.imgur.com/9OGDm1K.png)
(https://i.imgur.com/FTRWM11.png)

Esto en tiempo de ejecucion.


Insisto, si no es malloc esto se tiene que deber a algun sistema de seguridad que proteja al OS de ataques de denegacion de servicio por parte de programas...

Ha de ser que nunca habia cargado tantas entradas en una lista enlazada... Siempre las habia hecho por practicar con unas doscientas como maximo. ¿Son tan lentas en realidad? ¿Si es asi como es que programas como GTA V que cargan 2 GB en memoria lo hacen en menos de dos minutos? Mi programa esta cargando 20 MB   :huh:

Obviamente se debera a las habilidades de programacion. Supongo que intentare algo que no sean listas o que implique reservar memoria del heap...

Eh, entonces no tarda 40 minutos en cargar el archivo en memoria... Tarda 40 minutos en hacer el copiado a tu __quotesmem. ¿Donde haces el malloc en esta función? Idealmente no vas a querer llamar a esta función millones de veces... Vas a querer asignar un espacio considerable porque el coste de la interrupción es alto.

Aún así, algo esta haciendo windows si te esta limitando el % de utilización de CPU. ¿Alguna configuración de energía?

Idealmente no querras llamar esta funcion millones de veces

A malloc la llamo tantas veces como filas haya en el archivo, y en este hay once millones...

Esa funcion solo carga la fila actual en la estructura, en bQuotesmem, luego ese puntero es recogido por el caller de la funcion y llama a otra que mete la estructura en la lista enlazada (pero claro, cada vez que la llama, es decir, por fila, reserva memoria nuevamente)

¿Entonces si se debe a eso?

Si el programa tiene un solo hilo ese es el comportamiento esperado y logico.

Ejemplo, 12 procesadores/nucleos:
(https://i.ibb.co/ypjYFHz/waste.png)

#include <cstdio>
 
void main()
{
for (int x = 0; ; x++);
}

Usa el 100% de un nucleo/proceador, ni uno solito mas, el S.O. no puede poner en ejecucion UN hilo en varios procesadores/nucleos a la misma vez por obvias razones.

---

#include <windows.h>
#include <cstdio>
 
DWORD WINAPI WasteThread(LPVOID lpParam) 
{ 
	for (int x = (int)lpParam; ; x++);
}
 
void main()
{
for (int x = 0; x < 3; ++x)
 CreateThread(NULL, 0, WasteThread, (LPVOID)x, 0, nullptr);
for (int x = 0; ; x++);
}

(https://i.imgur.com/rMMfsTe.png)

Con 4 hilos (el principal y los 3 creados) pasa a consumir (100 / 12 * 4) = 33% de CPU.

Si, Eternal Idol, entiendo que la ejecucion de un ciclo no puede ser dividida, pero lo que no entiendo es por que disminuye, porque no es que sea baja la velocidad, es que disminuye con el tiempo, es decir, es mas rapida en un momento y mas lenta a medida que pasan los segundos... eso es lo que no logro comprender

---

¿Es eso lo que esta detectando el sistema? ¿Un waste.exe?

Exacto

No se. ¿Te estas quedando sin RAM? Tu programa opera con memoria virtual, eventualmente tendra que paginar si no paras de reservar. ¿Estas ordenando los datos a medida que los procesas? Con unos pocos, al principio, el ordenamiento es mucho menos costoso ...


No; waste.exe es el ejecutable generado con el codigo que deje, en sus dos versiones. El sistema no detecta nada, esa es una conclusion apresurada y sin respaldo.

marax: edita los mensajes por favor en lugar de crear dos consecutivos.

Vaya, juraría que windows le daba prioridad a uno o dos núcleos por defecto. ¿Quizás mejore el rendimiento si le das una afinidad a los primeros dos cores? Siendo el proceso de un solo hilo...

Edit: Aún así, no creo que mejore el rendimiento drásticamente.

Ya lo se ya lo se... Fue una metafora. Me referia a que si el sistema operativo estaba detectando un programa que aparentemente no esta haciendo nada mas que dar vueltas en la nada.

---

Ya se que pasa... Comente la linea que llama a la funcion que reserva memoria y cargo los 20 MB en menos de tres segundos  :xD :xD :xD :xD :xD :xD

No se por que malloc es tan lenta... Bueno. Supongo que tendre que arreglarmelas sin listas enlazadas... A saber como hago eso... En fin.

Muchisimas gracias en verdad... No se cuanto habria tardado en darme cuenta de eso por mi mismo...

3 segundos... hijo de p*ta...

Si ese fuera el caso no le daria el 100% de un procesador logico a cada hilo de waste.exe  ;)


Exactamente lo mismo de arriba.

Nada... La afinidad igual no era el problema. Me hubiera gustado que fuera cuestion solo de ajustar la afinidad porque no tendria que volver a programar todo otra vez xd

---

Por si a alguien le interesa:

Ya que de antemano conozco el tamaño del archivo, lo que hice fue modificar la funcion que adhiere al final de la lista creando un nuevo espacio de memoria para que en vez de eso simplemente cargase en un espacio mayor anteriormente reservado sumando el tamaño de la lista:

Es decir, de:

struct __quotesmem *newq=(struct __quotesmem *)malloc(sizeof(struct __quotesmem));
...
 
quotesmem->next=newq;

A:

memcpy((struct __quotesmem *) &quotesmem[i],
               (struct __quotesmem *) &newq,
               sizeof (struct __quotesmem));
 
        quotesmem[i].next=NULL;
        quotesmem[i-1].next=&quotesmem[i];
        quotesmem[i].last=&quotesmem[i-1];

Asi no tuve que modificar el comportamiento del programa entero ya que esta totalmente basado en listas enlazadas.

---

Gracias de nuevo.

Hola, tal vez usando Virtual List mejores la velocidad de carga:

https://www.google.com/search?q=Virtual+list+en+c

Por otro lado podes usar Threads, por ejemplo que tú programa cree un hilo/thread por cada 100/300/500 mil filas.

La razón de porque el programa trabaja cada vez más lento cuando va cargando las filas, puede ser porque está cargando constantemente en memoria los datos sin ser liberada, deberías liberar memoria después del volcado de datos, mira aquí que interesante esto:

(https://i.postimg.cc/L5btv3Z7/IMG-20211021-180822-895.jpg)

https://www.google.com/search?q=liberar+memoria+free+c

Vos tenés problema con la función malloc() y existe la función free() para justamente liberar memoria.


Saludos

marax: de nada, me alegro de que lo hayas solucionado.

Danielㅤ: super intersante, tambien estan los operadores new y delete.

Iba a señalar que me perdía, porque por un lado habladas de cargar el fichero de 20 mb. y luego en otro mensaje decías que lo cargadas inmediato (que es lo lógico)... y también que usabas 11mill millones de filas... que no entendía de donde salían sobre 20Mb. (salvo combinaciones con dichos elementos, pero que no explicaba explicitamente, pues se hablabas de estructuras,registros) ... pero el tema parece finalmente aclarado, así que así no tiene sentdo darle más vueltas.

Solo indicarte que las listas enlazadas son una estructura interesante cuando de lo que se trata es de hacer añadido dinámico y de antemano no se sabe cuanto ha de ser dicho tamaño.
Pero solo es útil finalmente si el resorrido que se precisa usar es secuencial, si el recorrido preciso es aleatorio, entonces la listas enlazadas tienen un pobre rendimiento, porque para ir hasta el índice 20millones cuando hay mill millones de items, requiere ser recorrido uno a uno desde el nodo raíz o desde el nodo final (si es doblemente enlazada).
Si tiras de estructuras que provee el lenguaje, se le supone un rendimiento eficaz (digamos que estará optimizado), si en cambio es una implementación propia, al caso conviene cuando menos mantener un item 'actual', de modo que un salto a otro punto distante pueda verificarse desde que punto queda más cerca: raiz, final o actual y la dirección de avance, para hacer el recorrido lo más óptimo posible en ese aspecto.
Mantener un item 'actual', complica el diseño de la implementación porque debe mantenerse con cada operación que lo afecte, así el costo del resto de operaciones aumenta a cambio de ser más óptimo en acceso.

En definitiva  tienes que tener claro si la lista enlazada es la mejor estructura que precisas en tus pesquisas. Cada estructura de datos tiene su fuerte y ninguna es óptima en cada punto.

Hola Daniel, gracias por tu respuesta.

El problema era este: Mira la funcion que usaba para añadir entradas en la lista enlazada:

int QuotesMemAddEnd (struct __quotesmem **qm, struct __quotesmem qmData)
{
    struct __quotesmem *aux=(struct __quotesmem *)malloc(sizeof(struct __quotesmem));
    struct __quotesmem **base;
    if(aux==NULL)
    {
        return MTERR_NOT_ENOUGH_MEMORY;
    }
 
    memcpy((struct __quotesmem *) aux,
           (struct __quotesmem *) &qmData,
           sizeof (struct __quotesmem));
 
    aux->next=NULL;
 
    if(*qm==NULL)
    {
        aux->last=NULL;
        *qm=aux;
    }
    else
    {
        base=qm;
        while((*base)->next!=NULL)
        {
            base=&((*base)->next);
        }
 
        aux->last=*base;
        (*base)->next=aux;
    }
 
    return 0;
}

Este programa lo hice con el fin de lidiar con muchos datos, y las pruebas del mismo las hacia precisamente con pocos datos, para no enrollarme en la depuracion. La cuestion fue algo muy curioso... Precisamente porque usaba pocos datos para probarlo, no me di cuenta del problema: Nunca me gusto usar el concepto de cabeza en mis listas enlazadas, siempre me parecio una perdida de tiempo porque nunca lidie con mas de diez kilobytes en una lista enlazada (y esto ya es monumental).

No se si te fijaste en que la lista recorre cada elemento hasta llegar a la cabeza para entonces añadir el siguiente. Lo que pasa es que cuando son demasiadas entradas el programa tiene que recorrer tantas cuantas sean, tantas cuantas sean veces. Es decir, en "Tiempo parabolico" (El tiempo se elevaria al cuadrado, mas o menos) Y por eso justamente la funcion era cada segundo mas lenta, porque iba recorriendo mas millones de entradas a medida que se añadian, basicamente lanzando el rendimiento por la borda  :xD

Ni malloc, ni nada... Pura pereza de programador...

De todas formas alojar memoria para todo el archivo de una vez me vino mejor. Lo seguire haciendo.

---

Que preciso   ::)
Diste en el blanco, Serapis.

Podrías haber simplemente haber guardado una referencia a la cola para que la inserción no sea O(n)...

Lo se. En la proxima modificacion eso hare... Y cambiare a malloc por HeapAlloc. Me imagino que es poca la diferencia de tiempo entre las dos pero como es un factor proporcional al final compensa.

Gracias.

Buenas noches.