[مایکل لینچ] با وضعیت عجیبی مواجه شد. چرا کامپایل پس از آن برنامه خود را تقریبا 10 برابر اجرا می کرد سریعتر از اجرای برنامه به تنهایی؟ [مایکل] در حین محک زدن یک پروژه برنامه نویسی با این مشکل مواجه شد، آن را با موارد ضروری آن برای تکرارپذیری و تجزیه و تحلیل مقایسه کرد و متوجه شد که مدل ذهنی نادرستی از نحوه عملکرد خطوط لوله bash را برجسته می کند.

وضعیت اینجاست اولین کاری که برنامه کاهش یافته [مایکل] انجام می دهد شروع یک تایمر است. سپس به سادگی می خواند و تعدادی بایت از آن را می شمارد stdin، سپس چاپ می کند که چقدر طول کشید تا این اتفاق بیفتد. هنگام اجرای برنامه آزمایشی به روش زیر، حدود 13 میکروثانیه طول می کشد.

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

هنگام اجرای مستقیم برنامه (از قبل کامپایل شده)، زمان اجرا به 162 میکروثانیه افزایش می یابد.

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

باز هم، تنها تفاوت بین zig build run و ./zig-out/bin/count-bytes این است که ابتدا کد را کامپایل می کند، سپس بلافاصله آن را اجرا می کند. دومی به سادگی برنامه کامپایل شده را اجرا می کند.

چگونه می توان یک مرحله کامپایل اضافی اضافه کرد کاهش زمان اجرا؟ معلوم شد که مدل ذهنی [مایکل] از نحوه عملکرد خطوط لوله bash نادرست بوده است، و او کار بسیار خوبی انجام می دهد. توضیح می دهد که آنها در واقع چگونه کار می کنند و چرا این باعث این رفتار عجیب شده است داشت می دید

به طور خلاصه، دستورات در خط لوله bash به صورت متوالی راه اندازی نمی شوند. همه آنها به طور همزمان راه اندازی شده و به صورت موازی اجرا می شوند. این بدان معنی بود که وقتی مستقیماً اجرا می شد، برنامه شمارنده بایت [مایکل] بلافاصله راه اندازی می شد. سپس حدود 150 میکروثانیه منتظر ماند و کاری انجام نداد echo '00010203040506070809' | xxd -r -p بخشی از خط لوله به تحویل داده های خود برای خواندن برنامه رسید. این جایی است که زمان اجرای اضافی هنگام اجرای نسخه کامپایل شده از قبل بدست می آید.

پس چرا کامپایل آن ابتدا سریعتر اجرا می شود؟ همان دلیل اصلی: زمانی که zig build run دستور شروع می شود، ابتدا کمی زمان صرف کامپایل برنامه می کند. سپس هنگامی که برنامه کامپایل شده واقعاً راه اندازی شد (و تایمر اجرای خود را شروع کرد)، داده های ورودی از خط لوله bash از قبل آماده است. بنابراین، برنامه تازه کامپایل شده در زمان کمتری اجرا می شود، زیرا منتظر نمی ماند تا داده های قبلی در خط لوله در دسترس قرار گیرند.

این یک نگاه جالب به نحوه عملکرد خطوط لوله bash در زیر کاپوت است و ما از جزئیاتی که [Micheal] در کل سفر و توضیحات ارائه می دهد خوشحالیم. دیر یا زود، جزئیاتی مانند این ظاهر می شوند و باعث می شوند برخی ابروها بالا بروند، مانند کاربری که کشف کرده است. موارد لبه مشکل ساز در مورد فضاهای موجود در دستورات ssh.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://hackaday.com/2024/03/28/is-your-mental-model-of-bash-pipelines-wrong/