Komprimera dokument i valfri storlek genom att tillämpa parallellitet

Parallellt arkiv: Släpp lös kraften i flerkärnig bearbetning

Överblick

De flesta komprimeringsalgoritmer utformades för enkärniga processorer. Men i en tid präglad av flerkärniga processorer är det fördelaktigt att använda alla dina processorkärnor för att påskynda arkivskapandet. Aspose.ZIP tillhandahåller denna funktion för vissa arkivformat.

Parallella metoder på BZIP2-, LZIP- och XZ-arkiv

Parallellisering är möjlig på grund av blockkaraktären hos dessa algoritmer. På programnivå använder dessa arkiv ett vanligt tillvägagångssätt för komprimering med flera kärnor. Användaren kan ställa in antalet trådar via egenskapen CompressionThreads . Så om den här egenskapen är mer än en skulle flera CPU-kärnor användas.

Sample 1 – Parallel compression to BZIP2    using (Bzip2Archive archive = new Bzip2Archive())
    {
        archive.SetSource("data.bin");
        archive.Save("archive.bz2", new Bzip2SaveOptions() { CompressionThreads = 4 });
    }

Sample 2 - Parallel compression to LZIP    var settings = new LzipArchiveSettings(16777216) { CompressionThreads = 4 }
    using (LzipArchive archive = new LzipArchive(settings))
    {
        archive.SetSource("data.bin");
        archive.Save("archive.lz");
    }

Sample 3 - Parallel compression to XZ    using (Bzip2Archive archive = new Bzip2Archive())
    {
        archive.SetSource("data.bin");
        archive.Save("archive.bz2", new Bzip2SaveOptions() { CompressionThreads = 4 });
    }

Hur man zippar en mapp med .NET

ZIP-arkiv tjänar till att komprimera och konsolidera en eller flera filer eller mappar till en enhetlig behållare. I .NET kan du använda klassen ZipFile för att arbeta med ZIP-filer och komprimering. Det primära syftet med arkivering är vanligtvis att minska filstorleken för lagring eller överföring, samtidigt som krypteringsåtgärder införs för ökad säkerhet. Utöver traditionella filkomprimeringsverktyg kan automatiska komprimerings-/extraheringsfunktioner hittas i olika skrivbords- och webbapplikationer, vilket underlättar uppgifter som att ladda upp, ladda ner, dela eller kryptera filer.

7Z LZMA2-arkiv

En av komprimeringsmetoderna i 7Z-format är LZMA2 , som kan komprimeras i flera trådar. På samma sätt som tidigare typer av arkiv kan du ställa in antalet trådar via CompressionThreads-egenskapen.

Sample 1 – Parallel compression to 7Z LZMA2    var settings = new SevenZipEntrySettings(new SevenZipLZMA2CompressionSettings(){ CompressionThreads = 4 });
    using (SevenZipArchive archive = new SevenZipArchive(settings))
    {
        archive.CreateEntry("first.bin", "data.bin");
        archive.Save("result.7z");
    }

Parallell metod på ZIP-arkiv

För tidigare arkivklasser tillämpades parallellisering antingen på block- eller algoritmnivå. För ZIP-arkivet är det möjligt på ingångsnivå. För att göra det instansiera ParallelOptions om arkivlagring.

Sample 1 – Parallel compression to zip    using (Archive archive = new Archive())
    {
        archive.CreateEntries(@"C:\Data");
        archive.Save(zipFile, new ArchiveSaveOptions()
        {
            ParallelOptions = new ParallelOptions() 
            { ParallelCompressInMemory = ParallelCompressionMode.Auto }
        });
    }

Inställningsstrategin Parallel-Compress-In-Memory används för att multitaska

Att ställa in ParallelCompressInMemory indikerar den strategi vi väljer att multitaska. Här är tre alternativ :
ParallelCompressionMode.Never: komprimering av alla poster är sekventiell. Endast en CPU-kärna fungerar på komprimering och rensar komprimerad data när den kommer.
ParallelCompressionMode.Always: Det tvingar fram komprimering av poster i olika trådar oavsett poststorlek, tillgängligt minne och andra faktorer. Varje CPU-kärna komprimerar samtidigt en fil och behåller dess komprimerade data i RAM. När posten är komprimerad spolar den till resultatströmmen. Om din RAM-mängd är liten och den totala storleken på några N poster (där N är antalet CPU-kärnor) är enorm kan det hända att allt RAM-minne som är tillgängligt för CLR töms och OutOfMemoryExcepton uppstår.
ParallelCompressionMode.Auto: Den uppskattar CPU-kärnor, storlekar på poster, tillgängligt minne och väljer om poster ska komprimeras parallellt eller sekventiellt. I detta läge ska vissa mindre poster komprimeras parallellt medan andra sekventiellt. LZMA- och PPMd-poster komprimeras inte parallellt på grund av hög minnesförbrukning. Generellt är det säkert att gå med det här alternativet; Aspose.ZIP är försiktig med uppskattningar och växlar till sekventiell komprimering som en reserv. Det finns ytterligare en egenskap för ParallelOptions för detta läge - AvailableMemorySize. Det är meningslöst för något annat läge. Grovt sett är det den höga gränsen för allokerat minne samtidigt som man komprimerar poster med alla CPU-kärnor, i megabyte. Aspose.ZIP använder det numret för att uppskatta den största storleken på posten som är säker att komprimeras parallellt. Poster över tröskeln som ska komprimeras sekventiellt. AvailableMemorySize är ett tveeggat svärd: om det är för högt inställt med enorma poster kan det leda till att RAM-minnet tar slut, intensivt utbyte, och kan till och med vara minneslöst undantag. Om de är för lågt inställda kommer de flesta av posterna att komprimeras på ett sekventiellt sätt utan någon större hastighet. Så sofistikerade användare kan tilldela det med tanke på en avvägning.
Vi uppmuntrar dig att spela med olika lägen för parallell komprimering av dina typiska data för att avgöra vilka de bästa inställningarna i ditt fall är.