S'il vous plaît dites-moi ce qui ne va pas avec mon filetage!

Question

J'ai une fonction où je vais compresser un tas de fichiers dans un seul fichier compressé .. il prend beaucoup de temps (pour compresser), donc j'ai essayé d'implémenter le filetage dans mon application .. Si j'ai 20 fichiers pour la compression , J'ai séparé cela comme 5 * 4 = 20, afin de faire que j'ai des variables séparées (qui sont utilisées pour la compression) pour tous les 4 threads afin d'éviter les verrous et je vais attendre jusqu'à ce que les 4 threads finit .. Maintenant les threads fonctionnent mais je ne vois pas d'amélioration dans leurs performances ... Normalement, il faudra 1 min pour 20 fichiers (par exemple) après la mise en œuvre du threading ... il y a seulement 5 ou 3 secondes de différence, parfois la même chose. ici i affiche le code pour 1 fil (il est donc pour les fils Autres3)

//main thread 
    myClassObject->thread1 = AfxBeginThread((AFX_THREADPROC)MyThreadFunction1,myClassObject); 
    .... 

    HANDLE threadHandles[4]; 
    threadHandles[0] = myClassObject->thread1->m_hThread; 
    .... 

    WaitForSingleObject(myClassObject->thread1->m_hThread,INFINITE); 

UINT MyThreadFunction(LPARAM lparam) 
{ 

    CMerger* myClassObject = (CMerger*)lparam; 
    CString outputPath = myClassObject->compressedFilePath.GetAt(0);//contains the o/p path 
    wchar_t* compressInputData[] = {myClassObject->thread1outPath, 
        COMPRESS,(wchar_t*)(LPCTSTR)(outputPath)}; 
    HINSTANCE loadmyDll; 
    loadmydll = LoadLibrary(myClassObject->thread1outPath); 
    fp_Decompress callCompressAction = NULL; 
    int getCompressResult=0; 
    myClassObject->MyCompressFunction(compressInputData,loadClient7zdll,callCompressAction,myClassObject->thread1outPath, 
        getCompressResult,minIndex,myClassObject->firstThread,myClassObject); 
    return 0; 
} 

Answer 1

Tout d'abord, vous n'attendez sur un des fils. Je pense que vous voulez WaitForMultipleObjects. En ce qui concerne le manque d'accélération, avez-vous considéré que votre goulot d'étranglement réel n'est PAS la compression mais le chargement du fichier? Le chargement du fichier est lent et 4 threads en concurrence pour les tranches de temps du disque dur "pourraient" même entraîner une baisse des performances.

C'est pourquoi l'optimisation prématurée est mauvaise. Vous avez besoin de profiler, de profiler et de profiler à nouveau pour déterminer où se trouvent vos goulots d'étranglement.

Editer: Je ne peux pas vraiment commenter votre WaitForMultipleObjects à moins que je vois le code. Je n'ai jamais eu aucun problème avec moi-même ...

Comme pour un goulot d'étranglement. C'est une métaphore si vous essayez de verser une grande quantité de liquide dans un cylindre en le renversant à l'envers, puis l'eau part à un rythme constant. Si vous essayez de le faire avec une bouteille, vous remarquerez qu'il ne peut pas le faire aussi vite. C'est parce qu'il y a seulement beaucoup de liquide qui peut s'écouler à travers la partie fine de la bouteille (sans parler de l'air qui y pénètre). Ainsi la limitation de la vidange de votre eau du récipient est limitée par le col de la bouteille (la partie fine). En programmation, lorsque vous parlez d'un goulot de bouteille, vous parlez de la partie la plus lente du code. Dans ce cas, si vos threads passent le plus clair de leur temps à attendre que le chargement du disque se termine, vous allez obtenir très peu d'accélération en multi-threading, car vous ne pouvez charger beaucoup de choses en même temps. En fait, lorsque vous essayez de charger 4 fois plus d'une fois, vous commencez à trouver que vous devez attendre aussi longtemps que la charge se termine. Dans votre cas, vous attendez et une fois compressé vous compressez. Dans le cas des 4 threads, vous attendez 4 fois plus de temps pour que toutes les charges soient terminées et vous compressez les 4 fichiers simultanément. C'est pourquoi vous obtenez une petite accélération. Malheureusement, en raison du fait que vous passez le plus clair de votre temps à attendre que les charges soient terminées, vous ne verrez rien de plus proche d'une accélération de 4x. D'où le facteur limitant de votre méthode n'est pas la compression mais le chargement du fichier à partir du disque et par conséquent il est appelé un goulot d'étranglement. Edit2: Dans un cas comme vous suggérez, vous trouverez la meilleure accélération en éliminant le temps d'attente pour le chargement des données à partir du disque.

1) Si vous chargez un fichier sous forme de plusieurs pages de disque (généralement 2048 octets mais que vous pouvez interroger les fenêtres pour obtenir la taille), vous obtenez les meilleures performances de chargement possibles. Si vous chargez des tailles qui ne sont pas un multiple de ceci, vous obtiendrez une performance assez sérieuse.

2) Regardez le chargement asynchrone. Par exemple, vous pouvez charger tout le fichier 2 (ou plus) dans la mémoire pendant que vous traitez le fichier 1. Cela signifie que vous n'attendez pas la fin du chargement. C'est peu probable, cependant, vous aurez une grande vitesse ici car vous aurez probablement encore attendre le chargement. L'autre chose à essayer est de charger des "morceaux" du fichier audio de manière asynchrone.à savoir:

• charge morceau 1.
  
• Démarrer morceau 2 chargement.
  
• Morceau de traitement 1.
  
• Attendez que le bloc 2 se charge.
  
• Commencer le tronçon 3 chargement.
  
• morceau de processus 2.
  
• (Et ainsi de suite)

3) Vous pouvez simplement acheter un disque plus rapide.