چند روز پیش داشتم مقاله های اقای Brett Cannon ، یکی از توسعه‌دهنده های core پایتون، رو میخوندم که رسیدم به این مقاله: بخش هاییش رو براتون اینجا میگم. خودمون هم تا حالا بسیاار این بحث هارو شنیدیم و خوندیم و حتی خودمون هم توش شرکت کردیم که: پایتون ک نده، پایتون سرعتش خیلی کمه نرید سمتش. خوب نیست. کدوم شرکتی سرعت نمیخواد. یا حتی یک سری‌ها پا رو فراتر میگذارن که پایتون خیلی ساده‌ست و در و پیکر نداره. شما یک سری کد رو حفظ میکنید و همون هارو تکرار میکنید. شما اصلا مهارت حل مسیله یاد نمی‌گیرید و از این جور صحبت ها. یک سری‌ها هم میگن: نه شما حتما باید در شروع برنامه‌نویسی از یک زبانی مثل سی/سی‌پلاس‌پلاس شروع کنید تا عمق پیدا کنید (که خودمون هم می‌دونیم . عمق پیدا کردن با چهار روز آموزش دیدن از اون زبان حاصل نمیشه. . همون چهار روز آموزش دیدن، تازه ضرر هم می‌زنه به طرف چون زبان های مختلف، طبیعت های متفاوتی دارن و نوع تفکر در اون ها بالاخره با باقی زبان ها فرق میکنه و . چرا دانشگاه های تاپ آمریکا (مثل MIT ) از قول گویدو ون راسم دارن با پایتون شروع میکنن؟ ! ) بعضی‌های دیگه هم (از امثال مدحج) میگن نه بین فلان زبان و پایتون اون یکی بهتره. چرا؟ چون سوییچ کردن از پایتون به دیگر زبان‌ها سخته‌(که باید ازشون سوال پرسید اولا این جمله چرا باید درست باشه؟ و ثانیا مگه ما زبان یاد میگیریم که بعدش حتما سوییچ کنیم روی یه چیز دیگه؟ ) اما سوال اینجاست که آیا واقعا این صحبت ها درستن؟ چندتامون (بعضا ) بخاطر این صحبت ها از پایتون ناامید شدیم و می‌خواستم بریم سراغ چیز دیگه‌ای؟ (یا حتی رفتیم؟ ! یک مثال کوچولو ببینیم: خب به شما گفته شده تعدادی از اعداد دنباله فیبوناچی رو چاپ کنید. چیزی که اول از همه به ذهن میرسه خوب فرمول بازگشتی دنباله هست: fib ( n ) = fib ( n - ) + fib ( n - ) where n = - > and n = - > خب میای و می‌نویسی تا چندین شماره اول اصلا حس نمیشه که این کنده. و مشکل شما حل شده و براتون کافی بوده. اما میره جلو تر و می‌بینی واقعا دیگه این کنده: (اگه این مقاله رو نخونده باشی، و صحبت های دیگران روت تاثیر گذاشته باشن: میگی نه این پایتون به درد نمی‌خوره! اما بیا طبق اون چرخه‌ای که معرفی شد پیش بریم: خب یکی از راه‌حل هایی که همین الگوریتم بازگشتی مارو سریع تر میکنه cache کردن، مقادیر محاسبه شده‌ست: این خودش سرعت رو خیلی بهبود می‌بخشه و می‌تونه آخرین قدم ما باشه و برامون کافی باشه. اما میگید نه، باز هم کنده بیاید الگوریتم رو عوض کنیم: یهو می‌بینی بووووم! چقدر خوب بود سرعت واقعا زیاد شد. فهمش هم چقدر راحت تر از اون تابع بازگشتی شده! این یک مثال ساده بود اما خییلی جا های دیگه میشه دیدش. بیاید چند تا از قدم هایی که ایشون به ما گفتن رو بررسی کنیم: شما بالاخره باید از یجایی شروع کنید و به لطف پایتون که طوری طراحی شده که to make you productive ، شما خیلی راحت می‌تونید یه چیزی رو بنویسید و خیلی سریع به نتیجه برسید و احتمالش هم بالا هست که که اون کد به اندازه کافی سریع عه و دیگه کار شما تموم شده: ) این یعنی واقعا خیلی وقت ها اون‌تصوری که ما از کندی داریم و اینکه مثلا باید این کد حتما حتما زیر نیم ثانیه ران بشه غلطه. یکی از مدرسان پایتون، آقای Tim Buchalka ، توی دوره‌ای که برای پایتون دارن یه مثال قشنگی رو میزنن. ایشون میگن این کد رو ببینید: بیاید فرض کنیم کد بالا قرار توی دو میلی ثانیه انجام میشه، و کد زیر فرض کنیم توی یک میلی ثانیه انجام میشه. خب فرقش چیه؟ گفت: فرض کنید کد شما داره توی یک جت جنگنده اجرا میشه و اون جت در هر ثانیه متر میره. خب هر میلی ثانیه برای این جت چند متر میشه؟ میشه . متر. اینجاست که مهم میشه از کد پایینی استفاده کنیم تا کد بالایی: ) این کد رو ببینید: خب فرقش چیه؟ نتایج که فرقی نمی‌کنه! اماااا خیلی فرق میکنه: در واقع membership testing در داده ساختار هایی مثل list و tuple (که ایندکس دارن و ترتیب دارن) به صورتی خطی هست، یعنی پایتون یکی یکی به ترتیب ازشون آیتم میگیره و چک میکنه. امااا در چیزی مثل set ، این قضیه برقرار نیست و چون از hash map ها استفاده شده خیییلی سریع تر در اون المنت ها پیدا میشن. فرقی بین چک کردن توی لیست و ست نیست، مثلا میشه . ثانیه، اما تفاوت جایی هست که میای یه آیتم از آخر رو می‌خوای چک کنی. در این مثال برای لیست مثلا میشه . ثانیه اما برای ست آچنان فرقی نمیکنه و تقریبا همون . بدست میاد. دیدید! اینجاست که لینوس توزوالدز میگه: خیلی هامون راجع به مفسر های دیگه‌ای که دارن توسعه داده میشن خبر داریم. اون‌هایی که هر کدوم با هدف خاصی نوشته میشن و دارن پیشرفت میکنن (هر چند بعضی‌ها شون دیگه راکد شدن. چیزی که مهمه اینکه مفسری رو بر ندارید که بخواید کدتون رو خییلی عوض کنید. چیزی رو انتخاب کنید که کمتر زحمت رو براتون داشته باشه. برای مثال: . . . . باز هم مثل قبل شما باید چند تا بررسی کنید و بهترین رو انتخاب کنید (برای مثال اگه منطقه های داغ کد شما (اونجایی که زمان زیادی میگیره) با اعداد سر و کار ندارن Numba گزینه خوبی نخواهد بود. . for Rust . for C . for C ++ . for C . و این یک لیست بلند بالایی واسه دیگر زبان ها و ابزار هاست. تفاوت اصلی این روش با روش قبلی اینکه، اینجا دیگه شما باید کمی کد نویسی کنید. اما اگر نیاز های performance شما دیگه، این گزینه راحت میتونه نیاز شما رو برطرف کنه. می‌تونید این راه رو شروع کنید، و آرام آرام در طول یک زمانی ببینید کل کد های پایتونی خود یا عوض کرده‌اید اما مهم‌ترین مسیله‌ای که وجود داره اینکه: "الگوریتم ها و طراحی‌های اون برنامه رو قبلا تایید کردید و ابزارهای زیادی هم برای تست اون کد دارید که می‌تونید استفاده کنید. " یکی از مهم‌ترین بند هایی که در این مقاله هست اینه: همه این حرفا به این معنی عه که شرکت‌ها براشون کم کردن هر cycle عه cpu واقعا ارزش داره، اما خب اون‌ها در عمل دارن دیتاسنتر می‌نویسن. اما شمایی که اصلا کاری به این چیز نداری، یه چرتکه بندازید ببینید پایین آوردن productivity برنامه‌نویس های تیم‌تون، به اسم اینکه "خب قراره سریع تر محاسبات انجام بشه، " به صرفه‌تره یا اینکه بیاید چهار تا سرور به سرور هاتون اضافه کنید؟