[Michael Lynch] a întâlnit o situație ciudată. De ce a fost compilarea și apoi rularea programului său de aproape 10x mai repede decât rularea programului de la sine? [Michael] a întâlnit această problemă în timp ce analiza un proiect de programare, l-a redus la elementele sale esențiale pentru repetabilitate și analiză și a descoperit că evidențiază un model mental incorect al modului în care funcționează conductele bash.

Iată situația. Primul lucru pe care îl face programul redus al lui [Michael] este să pornească un cronometru. Apoi pur și simplu citește și numără câțiva octeți din stdin, apoi imprimă cât de mult a durat până se întâmplă asta. Când rulați programul de testare în felul următor, durează aproximativ 13 microsecunde.

$ echo '00010203040506070809' | xxd -r -p | zig build run -Doptimize=ReleaseFast
bytes: 10
execution time: 13.549µs

Când rulați direct programul (deja compilat), timpul de execuție crește la 162 de microsecunde.

$ echo '00010203040506070809' | xxd -r -p | ./zig-out/bin/count-bytes
bytes: 10
execution time: 162.195µs

Din nou, singura diferență între zig build run și ./zig-out/bin/count-bytes este că primul compilează codul, apoi îl rulează imediat. Al doilea pur și simplu rulează programul compilat.

Cum se poate adăuga un pas suplimentar de compilare scădea timpul de executie? Se pare că modelul mental al lui [Michael] despre modul în care funcționează conductele bash a fost incorect și el face o treabă grozavă de explicând cum funcționează de fapt și de ce a cauzat acest comportament ciudat el vedea.

Pe scurt, comenzile dintr-o conductă bash nu sunt lansate secvenţial. Toate sunt lansate în același timp și se execută în paralel. Asta însemna că, atunci când este rulat direct, programul de contor de octeți al lui [Michael] a fost lansat imediat. Apoi a așteptat fără a face nimic pentru aproximativ 150 de microsecunde în timp ce echo '00010203040506070809' | xxd -r -p o parte din conductă a ajuns să-și livreze datele pentru ca programul să le citească. De aici provine timpul suplimentar de execuție atunci când rulează versiunea deja compilată.

Deci, de ce compilarea ei rulează mai repede? Același motiv de bază: când zig build run comanda începe, petrece puțin timp compilând programul mai întâi. Apoi, când programul compilat este de fapt lansat (și începe cronometrul de execuție), datele de intrare din conducta bash sunt deja gata. Așadar, programul proaspăt compilat se execută în mai puțin timp, deoarece nu stă în așteptare ca datele de la începutul procesului să devină disponibile.

Este o privire interesantă asupra modului în care conductele bash funcționează de fapt sub capotă și suntem încântați de detaliile pe care [Micheal] le pune în întreaga călătorie și explicație. Mai devreme sau mai târziu, detalii ca acesta apar și provoacă ridicarea unor sprâncene, cum ar fi utilizatorul care a descoperit cazuri marginale supărătoare în ceea ce privește spațiile din comenzile ssh.

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• PlatoData.Network Vertical Generative Ai. Împuterniciți-vă. Accesați Aici.
• PlatoAiStream. Web3 Intelligence. Cunoștințe amplificate. Accesați Aici.
• PlatoESG. carbon, CleanTech, Energie, Mediu inconjurator, Solar, Managementul deșeurilor. Accesați Aici.
• PlatoHealth. Biotehnologie și Inteligență pentru studii clinice. Accesați Aici.
• Sursa: https://hackaday.com/2024/03/28/is-your-mental-model-of-bash-pipelines-wrong/