کد های اسکریپتی به 0و1 تبدیل میشن؟

[k1.technology]

درود بر دوستان

میگن php تحت سرور هست و خروجی فایل html میده
ایا این کدهای php به 0و1 تبدیل نمیشن؟ یا اپاچی کار تیدیل اونو به html انجام میده یا نه؟
این که میگن اوپن سورس هست چطوریه که ما فقط کد سمت کلاینتو میبینیم که html هستن؟
خلاصه چه بلای سر کدهای php میاد ؟
وقتی کامپایل نمیشن نباید cpu رو استفاده کنند یعنی؟
من مثلا استفاده از cpu 0 % بود وقتی یه سایتیو باز کردم شد 3% درصد چه نقشی میتونه با cpu داشته باشه سایتی که باز میکنم؟

[MRmoon]

درود بر دوستان

میگن php تحت سرور هست و خروجی فایل html میده
ایا این کدهای php به 0و1 تبدیل نمیشن؟ یا اپاچی کار تیدیل اونو به html انجام میده یا نه؟
این که میگن اوپن سورس هست چطوریه که ما فقط کد سمت کلاینتو میبینیم که html هستن؟
خلاصه چه بلای سر کدهای php میاد ؟
وقتی کامپایل نمیشن نباید cpu رو استفاده کنند یعنی؟
من مثلا استفاده از cpu 0 % بود وقتی یه سایتیو باز کردم شد 3% درصد چه نقشی میتونه با cpu داشته باشه سایتی که باز میکنم؟

درود.

اساسی ترین مشکل افراد تازه وارد اینه که اپن سورس بودن پی اپ پی یعنی چی.

خوب ببین لینوکس هم اوپن سرورسه اما بعد از کامپایل میشه سورسش رو دید؟؟؟

پی اچ پی هم هم خودش اوپن سورسه.(سرورسش رو میتونه از تو خود php.net که به زبان C++ هست پیدا کنی) هم برنامه هایی که مینویسیی. یعنی هر جا بخوای استفاده کنی طرفی که فایل ها دسترسی داره میتونه کد هات رو ببینه. هر کسی که به کد ها دسترسی داره! کلاینت(به طور مثال مرورگر) نمیتونه به سورس پی اچ پی درسترسی داشته باشه و فقط کد های اچ تی ام ال رو دریافت می کنه.

وقتی هم که شما یه سایتو باز می کنی(کثلا xxx.com) اون cpu که درگیر میشه توسط مرورگر برای نشون دادن ظاهر سایت که به زبان html هست.

آپاچی هم به نوعی یک رابط هست.

زبان پی اچ پی هم یک زبان کامپایل شدنی نیست بلکه مفسر داره.

[k1.technology]

خوب خروجی که میده html هست ؟ ایا کد های html کامپایل میشن؟

[cpuram]

هر کدی برای فهم کامپیوتر یا سرور در پایین ترین سطح به 0 و 1 تبدیل میشه کاری به اتفاقات میانی ندارم آخر کار فقط 0 و 1 میفهمه.html هم بله توسط مرورگر کامپایل میشه.

[k1.technology]

من شاید منظور از کامپایل شدن رو خوب متوجه نشدم . مثلا وقتی ما یه عکسیو تو سیستم عامل باز میکنیم ایا کامپایلر این وسط در گیر میشه؟
هر کدی که به 0و1 تبدیل میشه کامپایلر میاد وسط؟!

[cpuram]

عکس یه فایل هست که کدهای برنامه html اونو باز میکنن.کلا کامپیوتر با 0 و 1 هست عکس هم به صورت 0 و 1 ذخیره شده.
ولی منظور شما اینه که php کامپایل میشه یانه که بله کامپایل میشه خروجیش html هست که توسط مرورگر دانلود و ترجمه میشه البته php زبان مفسری هست در مورد مفسر یه سرچ بزنید متوجه منظورم میشید.به هر حال بازم تاکید میکنم برنامه یا فایل فقط ابزارین که کامپیوتر با اونا کار میکنه پشت پرده فقط و فقط 0 و 1 هست.

[MMSHFE]

دوست عزیز، مرورگر کامپیوتر کاربر (که بهش میگیم کلاینت Client) چیزی بجز HTML و CSS و Javascript (یعنی کلاً کدهایی که سمت کلاینت اجرا میشن) نمیفهمه و بنابراین باید خروجی اسکریپتهای سمت سرور (چه PHP باشه، چه ASP.NET و...) کدی باشه با ساختارهای فوق. حالا وقتی شما آدرس فرضی mysite.com/test.php رو اجرا میکنید، یک درخواست از مرورگر شما میره به سمت کامپیوتر سرور که سایتmysite.com روش قرار داره و اسکریپت test.php اونجا اجرا میشه و خروجی اون در قالبهای مذکور، تحت عنوان پاسخ درخواست شما به مرورگرتون تحویل داده میشه. تا اینجا دیگه وظیفه سرور تمامه و از اینجا به بعد سیستم کلاینت میاد کدهای دریافتی رو پردازش میکنه و مثلاً اونجایی که تگ <table> گذاشتین جدول میکشه و اونجایی که مثلاً از تگ </ img> استفاده کردین عکس میگذاره و...

درسته که PHP یک زبان Open Source هست ولی این فقط به معنای اینه که میتونید از سایت رسمی php.net سورس خود زبان PHP (نه سایتهایی که باهاش نوشته شدن) رو دانلود کنید و درصورت نیاز و داشتن مهارت کافی در برنامه نویسی، یک زبان PHP سفارشی شده برای خودتون بسازین (کاری که فیسبوک انجام داده) و بجز این مورد، سورس هیچ سایتی که با PHP نوشته شده در اختیار بقیه نیست مگه اینکه به سرور نفوذ کنن (Hack) یا خودشون منتشر کنن که در حالت دوم به اون اسکریپت هم میگیم Open Source

کدهای PHP کامپایل نمیشن بلکه خط به خط خونده و اجرا میشن که به این روش میگیم تفسیر کدها و این روش هم بهرحال CPU رو درگیر میکنه اما نه CPU شما (کلاینت) بلکه CPU سرور. کامپایل یعنی یکبار کل کد شما توسط برنامه ای به اسم کامپایلر خونده بشه و به زبان معادل ماشین تبدیل بشه و در اجراهای بعدی، فایل زبان ماشین (که پسوند exe. یا com. و... توی ویندوز داره) اجرا میشه و زمانی صرف تبدیل به زبان ماشین شدن نخواهد شد و این مسئله سرعت کار رو بالا میبره اما درمقابل اگه سورس کد رو تغییر بدین، دوباره باید کامپایل بشه. زبانهای تفسیری مثل ‍PHP نیاز به این مورد ندارن چون هربار که اسکریپت اجرا میشه، خط به خط خونده و تبدیل میشن (همون زمان اجرا یعنی Run-time) و این مسئله سرعت رو اندکی کاهش میده ولی درعوض دیگه نیازی به کامپایل نیست چون کامپایل کردن، برای هر سیستم عامل فرق میکنه و فرضاً کدی که روی ویندوز کامپایل شده روی لینوکس کار نمیکنه.

البته اینجا یک ذهنیت اشتباه ممکنه پیش بیاد که یک عده بگن پس چون کدهای ASP.NET کامپایل میشن سرعت اجراشون از اسکریپتهای PHP بیشتره که باید بگم خیر چنین چیزی نیست چون کدهای NET. بعد از کامپایل به یک زبان واسط تبدیل میشن به اسم MSIL (مخفف MicroSoft Intermediate Language) نه زبان ماشین که هدف از این کار، ایجاد توانایی ارتباط بین کدهای نوشته شده با فرضاً VB.NET و #C بوده. حالا موقع اجرا دوباره هربار که کد اجرا میشه، یک کامپایلر دیگه به اسم JIT (مخفف Just In Time) میاد کد MSIL رو به زبان ماشین تبدیل میکنه و بخاطر همینه که برنامه های exe. نوشته شده با NET. رو نمیشه بدون خود فریمورک NET. اجرا کرد و مستقل نیستن. این دو مرحله کامپایل که یکیش هربار داره اتفاق میفته باعث میشه سرعت کدهای NET. بیشتر از PHP نباشه (از این نظر). البته مایکروسافت از این دو مرحله ای کردن کامپایل یک منظور دیگه هم داشت و اونهم Multi-Platformکردن این معماری با تقلید از Java و ماشین مجازی اون بود که عملاً توش مونده و کماکان برنامه های NET. صرفاً روی ویندوز قابل اجراست و توی لینوکس (حتی با وجود پروژه هایی مثل Mono) باز هم کارایی و راندمان مناسبی مثل ویندوز حاصل نشده و توی سیستمهای عامل دیگه مثل MacOS و... هم که رسماً هیچ کاری نکرده.

اون چیزی هم که دیدین CPU شما درگیر شده بخاطر اینه که مرورگرتون داره کدهای دریافتی رو تفسیر میکنه و یکسری کارها برای نمایش محتوای دریافتی انجام میده که این کارها روی کامپیوتر شما انجام میشه و برای همین CPU و RAM شما درگیر میشه که قطعاً درمقابل بار کاری که سرور برای تولید این محتوا متحمل شده (وصل شدن به دیتابیس و استخراج اطلاعات و تولید خروجی در قالب استاندارد HTML و چیدن مطالب استخراج شده از دیتابیس در مکان مناسب از قالب خروجی و...) خیلی کمتره ضمن اینکه سرور همزمان ممکنه به صدها یا هزاران نفر جواب درخواستهاشون رو بده و بخاطر همینه که اصولاً سرورها کامپیوترهای خیلی قدرتمندتری نسبت به PCها یا کامپیوترهای شخصی هستن.

ضمناً نه فقط بازکردن سایت، بلکه هر کاری که با سیستمتون انجام میدین (مثل حرکت دادن ماوس و فشردن کلیدهای کیبورد و...) با CPU سروکار داره چون پردازنده داره ورودیها و خروجیها رو کنترل میکنه. حتی وقتی هیچ کاری به ظاهر انجام نمیدین باز هم CPU داره کارهایی مثل بررسی وضعیت دستگاهها و بروزرسانی ساعت سیستم و... رو انجام میده (برای همینه که تا یک وسیله به سیستم ازطریق پورت USB وصل میشه سیستم میفهمه چون داره مدام وضعیتها رو چک میکنه).

CPU هم فقط 0 و 1 میفهمه ولی نباید این مسئله شما رو به اشتباه بندازه. قرار نیست ما هم با زبان 0 و 1 صحبت کنیم با کامپیوتر. برای همینه که سیستم عامل و زبانهای برنامه نویسی تولید شدن تا ما به زبان خودمون ارتباط برقرار کنیم و این برنامه ها دستورات ما رو به سیگنالهای الکتریکی 0 و 1 تبدیل کنن که CPU بفهمه چه کاری باید انجام بده. حتی همون بازکردن عکس و... هم که گفتین، به همین شکله و عکس که با فرمت خاص خودش (مثل JPG و PNG و BMP و...) ذخیره شده که هرکدوم قالب خاصی دارن و به شکل خاصی رمزنگاری میشن و بعداً موقع نمایش هم باید با فرمت مربوط به خودشون رمزگشایی بشن، برای اینکه به نمایش در بیان باید تبدیل به یکسری سیگنالهای 0 و 1 بشن. برای مثال هر نقطه از تصویر به سه طیف رنگ RGB یعنی قرمز و سبز و آبی تجزیه میشه (که هرکدوم عددی بین 0 تا 255 میشه) و این سینگالها به کارت گرافیک کامپیوتر ارسال میشه و اونهم برحسب همین اعداد به مانیتور دستور میده نقطه مربوطه رو با شدت نور مشخص شده از هرکدوم از این کانالهای رنگی روشن کنه که درنهایت رنگ ترکیبی موردنظر جلوی چشم شما شکل میگیره.

امیدوارم خوب توضیح داده باشم (هرچند خیلیهاش مربوط به PHP نبود ولی بنظرم برای اینکه از سردرگمی در بیاین لازم بود).

[MMSHFE]

پست قبل رو ویرایش کردم چون یادم رفته بود درمورد کامپایل توضیح بدم.

[eshpilen]

البته اینجا یک ذهنیت اشتباه ممکنه پیش بیاد که یک عده بگن پس چون کدهای ASP.NET کامپایل میشن سرعت اجراشون از اسکریپتهای PHP بیشتره که باید بگم خیر چنین چیزی نیست چون کدهای NET. بعد از کامپایل به یک زبان واسط تبدیل میشن به اسم MSIL (مخفف MicroSoft Intermediate Language) نه زبان ماشین که هدف از این کار، ایجاد توانایی ارتباط بین کدهای نوشته شده با فرضاً VB.NET و #C بوده. حالا موقع اجرا دوباره هربار که کد اجرا میشه، یک کامپایلر دیگه به اسم JIT (مخفف Just In Time) میاد کد MSIL رو به زبان ماشین تبدیل میکنه و بخاطر همینه که برنامه های exe. نوشته شده با NET. رو نمیشه بدون خود فریمورک NET. اجرا کرد و مستقل نیستن. این دو مرحله کامپایل که یکیش هربار داره اتفاق میفته باعث میشه سرعت کدهای NET. بیشتر از PHP نباشه (از این نظر).
من نمیدونم آیا واقعا JIT در هر بار اجرا دوباره از اول انجام میشه یا نه، ولی اگر بله، نمیدونم چرا! چون ضرورتی نیست و میشه خروجی کامپایل قبلی رو ولو در حافظهء موقت و با شرایط و مدت محدودی هم که شده کش کرد. بنده قبلا در این مورد تحقیق و سوال کرده بودم ولی آخرش هم جایی جوابش رو پیدا نکردم و کسی اطلاع دقیق و موثقی در این مورد نداشت.

و اما درمورد اینکه پرفورمنس سیستم دات نت ممکنه حداقل در بعضی از موارد از PHP بیشتر بشه، دلیل منطقی داره که اکثرا به ذهنشون نمیرسه یا در بحثها ازش غفلت میشه.
و اما علتش چیه.
یک قطعه ای از کد رو فرض کنید که پردازش نسبتا سنگینی رو انجام میده.
خب حالا این قطعه کد اگر فقط یک بار بخواد اجرا بشه، PHP اون رو خط به خط میخونه و اجرا میکنه و سرعت تفسیر خط به خط بالا نیست، دات نت هم میاد و اول به زبان ماشین کامپایل میکنه و بعد اجرا میکنه و با اینکه سرعت اجرای کد کامپایل شده بالاتره ولی زمانی که صرف کامپایلش شده باعث میشه سرعت اجرای دات نت هم در کل با PHP تفاوت چندانی نکنه.
اما حالا فرض کنید اون قطعه کد در داخل حلقه ای چیزی هست که قراره بارها و شاید صدها و هزاران و حتی میلیون ها بار اجرا بشه. اونوقت چی؟ اونوقت سرعت سیستم دات نت از نظر تئوریک میتونه از PHP بیشتر بشه، چون اون قطعه کد فقط یک بار کامپایل میشه ولی کد کامپایل شده (زبان ماشین) هزاران بار اجرا میشه و در هر بار این اجراها دیگه فرایند کامپایل وجود نداره و سرعت اجرای دستورات بالاست؛ اما PHP در هر بار از این هزاران بار میخواد باز حداقل یک بخشی از اون فرایند تفسیر رو دوباره انجام بده و سرعت هر بار اجرای کد پایین تره به نسبت و این کمتر بودن سرعت ضرب در تعداد تکرارها احتمالا یک اختلاف قابل توجهی در زمان کل صرف شده برای اجرای اون برنامه ایجاد میکنه به نسبت اجرا در سیستم دات نت.
البته بنده میدونم که برای PHP تفسیر بار اول زمان بیشتری صرف میکنه، چون کدها از حالت کدمنبع خوانا برای انسان به یک کد فشرده تر و بهینه تر مخصوص اجرای درونی توسط مفسر PHP تبدیل میشن، اما بهرحال این کد سطح پایین تر هنوزم کد ماشین نیست و بنابراین به اندازهء کد ماشین سرعت و بهینگی نداره.

[MMSHFE]

بهتره درمورد opcache در PHP تحقیق کنید. PHP میتونه دستوراتش رو کش کنه و فقط روال کار، تفسیر خط به خطه. همچنین APC رو هم بررسی کنید. ضمناً اینکه JIT هربار کامپایل میکنه حرف من نیست. توی کتاب رسمی خود مایکروسافت که John Sharp نوشته قید شده. هنوز هم تغییری توی این سیستم ایجاد نشده و گواهش هم عدم امکان اجرای مستقل برنامه های NET. بدون وجود فریمورکه. این یعنی اینکه همچنان کدهای exe. تولیدشده، Native Code نیستن و طبیعتاً برای اجرا در هربار نیازمند کامپایل خواهند بود. تا جایی که توی MSDN و... بررسی کردم هم خبری از کش کردن فایلهای اجرایی نبود و منطقی هم نیست که بخواد سیستم اینهمه فایل رو کش کنه و هربار هم چک کنه ببینه کش هنوز معتبره یا نه.

[eshpilen]

بهتره درمورد opcache در PHP تحقیق کنید.
اینا که میگی همه رو خودم میدونم، ولی شما به نحو مبهمی میگی که معلوم نیست منظورت چیه و چه استدلالی داری.
تاجاییکه میدونم PHP بطور پیشفرض در هر درخواست فایل PHP رو خط به خط میخونه و به opcode تبدیل میکنه (همون فرمت بهینه درونی خودش برای تفسیر نهایی)، مگر اینکه opcode cache روی اون نصب و فعال بشه، که بنظرم روی خیلی از هاستهای اشتراکی اینطور نیست و شاید نشه به این کار مجبورشون هم کرد.
دوما که حالا فرض گیریم opcode cache هم داشتیم؛ بهرحال این opcode ها کد ماشین نیستن و سرعت اجراشون به کد ماشین نمیرسه.


PHP میتونه دستوراتش رو کش کنه و فقط روال کار، تفسیر خط به خطه.
جان؟
دقیقتر توضیح بدید.


همچنین APC رو هم بررسی کنید.
خب چطور؟
این چیزی جدا/خارج از موارد و توضیحاتی هست که تاحالا گفتیم؟


ضمناً اینکه JIT هربار کامپایل میکنه حرف من نیست.
منم نگفتم حرف شماست. گفتم نمیدونم چرا باید اینطور باشه. شاید بخاطر بعضی مسائل فنی. ولی موضوع اینه که از نظر تئوریک ضرورتی در این کار نیست یا اینطور بگم که این رفتار قابل تغییره.


هنوز هم تغییری توی این سیستم ایجاد نشده و گواهش هم عدم امکان اجرای مستقل برنامه های NET. بدون وجود فریمورکه. این یعنی اینکه همچنان کدهای exe. تولیدشده، Native Code نیستن و طبیعتاً برای اجرا در هربار نیازمند کامپایل خواهند بود.
مثل اینکه متوجه چیزی که بنده گفتم نشدید. من میدونم که فایلهای اجرایی دات نت با پسوند exe محتوی MSIL هستن و نه کدهای ماشین. ولی موقعی که یک فایل exe دات نت رو اجرا میکنید طبیعتا یک بار کامپایل میشه به کد ماشین، پراسس مربوطه شروع به اجرا میکنه، و بعدش تا زمانیکه اون پراسس خاتمه نیافته همون کدهای ماشین حاصل از همون یک بار کامپایل اول هستن که اجرا میشن. حالا اگر ما یکسری دستورات داخل یک حلقه داشته بوده باشیم، معادل اون حلقه و کدها به زبان ماشین کامپایل شده و در پراسس اصلی موجود هستن و همونطور داخل حلقه اجرا میشن؛ هزار بار، صدهزار بار، میلیون ها بار. بهرحال این کدهای ماشین هستن که در نهایت داخل حلقه هزاران بار اجرا میشن. اما آیا در PHP اینطوره؟ خیر! PHP داره تفسیر میکنه و کد شما گرچه به opcode بهینه تری تبدیل شده، ولی در هر بار اجرای اون حلقه مفسر PHP داره اون opcode ها رو مجددا میخونه و اجرا میکنه که سرعت اجراش طبیعتا به سرعت اجرای کد ماشین نمیرسه.


تا جایی که توی MSDN و... بررسی کردم هم خبری از کش کردن فایلهای اجرایی نبود و منطقی هم نیست که بخواد سیستم اینهمه فایل رو کش کنه و هربار هم چک کنه ببینه کش هنوز معتبره یا نه.
این همه فایل؟
خیلی چیزهای دیگر رو باوجود حجم و تعداد بالا کش میکنن، بعد حالا به خروجی کامپایل که رسید نمیشه کش کرد یا این کار صرف نمیکنه؟! دقیقا چرا؟ فرق این کش کردن با کش کردن های دیگه چیه میگه؟ ما کوئری های دیتابیس رو کش میکنیم، خروجی اسکریپت ها رو کش میکنیم، نتایج خیلی پردازشهای دیگر رو کش میکنیم، ... یعنی در اون موارد چه تفاوت اساسی ای وجود داره.
سیستمهای کش الان از پس هرکاری برمیان. اگر هم فضای محدودی داشته باشیم طبیعتا سیستم کش میاد و یکسری entry های قدیمی رو حذف میکنه/با موارد جدید جایگزین میکنه. طبیعتا سیستم کش بر اساس الگوریتم هوشمند خودش به موارد جدید و/یا مواردی که تعداد بیشتری مورد استفاده قرار میگیرن اولویت میده. نیازی هم نیست که همهء موارد رو و همیشه کش کنه و همیشه از کش استفاده کنه. مثلا مواردی که کوچک بودن یا زمان کامپایل یا اجرای اونا خیلی کم بوده رو میتونه کش نکنه. همهء این آمارها در خود سیستم قابل دسترسی و استفاده است.

[MMSHFE]

وقتی میگم درمورد OPCache اطلاعاتتون کمه نگین نه:


OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request.

حتماً میدونید که bytecode با opcode داخلی زبان خیلی فرق داره و همچنین removing the need for PHP to load and parse scripts on each request هم فکر میکنم به اندازه کافی واضح باشه.

بهرحال کسی که اینقدر بهینگی در سطح دستورات داخلی حلقه ها نیازش باشه، با هاست اشتراکی کار نمیکنه و ضمناً OPCache توی نسخه 5.5 بصورت توکار دراومده و نیاز به نصب ازطریق PECL هم نیست. APC بیشتر شبیه اون چیزیه که شما گفتین:


The Alternative PHP Cache (APC) is a free and open opcode cache for PHP. Its goal is to provide a free, open, and robust framework for caching and optimizing PHP intermediate code.

که البته همین حد هم برای 90درصد کاربردها کافیه.


این همه فایل؟
خیلی چیزهای دیگر رو باوجود حجم و تعداد بالا کش میکنن، بعد حالا به خروجی کامپایل که رسید نمیشه کش کرد یا این کار صرف نمیکنه؟! دقیقا چرا؟ فرق این کش کردن با کش کردن های دیگه چیه میگه؟ ما کوئری های دیتابیس رو کش میکنیم، خروجی اسکریپت ها رو کش میکنیم، نتایج خیلی پردازشهای دیگر رو کش میکنیم، ... یعنی در اون موارد چه تفاوت اساسی ای وجود داره.
تا حالا با Dump گرفتن، حجم یک برنامه NET. رو وقتی به Native Code تبدیل میشه و Linker میاد Libraryهای NET. رو که استفاده شده میچسبونه به هم توی فایل اصلی بررسی کردین؟ یک برنامه 200 کیلوبایتی بالغ بر 30-20 مگابایت میشه. حالا تصور کنید صدها برنامه روی سیستم شما باشه که قراره همه کش بشن. حجم کش به کنار، مسئله پیگیری اینکه کش هنوز معتبره یا برنامه تغییر کرده رو هم درنظر بگیرین. بهرحال اگه موضوع ساده ای بود، شرکتی مثل مایکروسافت تا حالا کش کردن رو اعمال کرده بود.

[eshpilen]

وقتی میگم درمورد OPCache اطلاعاتتون کمه نگین نه:
حتماً میدونید که bytecode با opcode داخلی زبان خیلی فرق داره و همچنین removing the need for PHP to load and parse scripts on each request هم فکر میکنم به اندازه کافی واضح باشه.
البته opcode رو شما اول انداختی وسط و بنده هم همینطور حرف شما رو تکرار کردم که از نظر فنی خودم هم متوجه شدم دقیق نیست و احتمالا اشتباهه.
کاری که این سیستمها میکنن و در متن خودشون عبارتی که آمده bytecode است و نه opcode.
bytecode هم یک کد میانی است و کد ماشین نیست.
bytecode کدی فشرده/بهینه شده برای اجرا توسط مفسر یا ماشین مجازی است.

بهرحال کسی که اینقدر بهینگی در سطح دستورات داخلی حلقه ها نیازش باشه، با هاست اشتراکی کار نمیکنه و ضمناً OPCache توی نسخه 5.5 بصورت توکار دراومده و نیاز به نصب ازطریق PECL هم نیست. APC بیشتر شبیه اون چیزیه که شما گفتین:

که البته همین حد هم برای 90درصد کاربردها کافیه.

It stores precompiled script bytecode in shared memory
منبع: http://en.wikipedia.org/wiki/List_of_PHP_accelerators#Zend_Opcache_.28ex._Zend_ Optimizer.2B.29
پس اینم باز داره در سطح bytecode کار میکنه و کد ماشین نیست.
bytecode هم که مستقیم روی CPU اجرا نمیشه! یه مفسری چیزی این وسط داره میخونه و اجراش میکنه، که این خودش باعث مقداری کندی میشه (نه خیلی، ولی بهرحال از اجرای مستقیم کد ماشین کندتره).


تا حالا با Dump گرفتن، حجم یک برنامه NET. رو وقتی به Native Code تبدیل میشه و Linker میاد Libraryهای NET. رو که استفاده شده میچسبونه به هم توی فایل اصلی بررسی کردین؟ یک برنامه 200 کیلوبایتی بالغ بر 30-20 مگابایت میشه. حالا تصور کنید صدها برنامه روی سیستم شما باشه که قراره همه کش بشن. حجم کش به کنار، مسئله پیگیری اینکه کش هنوز معتبره یا برنامه تغییر کرده رو هم درنظر بگیرین. بهرحال اگه موضوع ساده ای بود، شرکتی مثل مایکروسافت تا حالا کش کردن رو اعمال کرده بود.

خب منم روی کش کردن اصرار ندارم. ولی گفتم از نظر تئوریک ممکنه.
خود PHP هم نگاه کنید در اوایل این شتاب دهنده ها و سیستم کش و این حرفا رو نداشته و به مرور اینا ساخته شدن و پیشرفت کردن.
بهرحال کش بحث اصلی من نیست و فعلا نمیخوام بیشتر روش وقت و انرژی صرف کنم.

[MMSHFE]

درسته و البته Bytecodeهای PHP هم ازنظر سرعت میشه گفت سرتر از MSIL هستن. بهرحال این تفاوتهای سرعت و بهینگی همیشه بین NET. و PHP بوده و من هم فقط خواستم این ذهنیت اشتباه پیش نیاد که ASP.NET بخاطر کامپایل شدن سریعتر از PHP عمل میکنه و همونطور که اینجا (http://en.wikipedia.org/wiki/Bytecode)در قسمت Execution توضیح داده، JIT هربار میاد Bytecodeها رو یکی یکی اجرا میکنه و عملاً چیزی به اسم کامپایل واقعی وجود نداره توی NET. و فقط یکبار در زمان Build پروژه است که کدها کامپایل و خطایابی میشن و اگه مشکلی نبود به MSIL تبدیل میشن.

[metal gear solid 4]

البته ASP از فریمورک .net استفاده میکنه که شرایط خاصی رو روی سرورها میطلبه. برنامه نویسان PHP هم اگر بهینه سازی ها براشون مهمه و سایتی دارند که نیاز به سرعت بالا داره از فریمورک phalconphp (http://phalconphp.com/en/)استفاده کنند تا بهترین نتیجه رو حاصل کنند. به هر حال phalconphp هم مثل .net یک فریمورک محسوب میشه برای زبان برنامه نویسی PHP.
البته فایل های خود فریمورک بوسیله ی C نوشته شدن و کامپایل شده هستند یا میتونید روی سرورهای لینوکس خودتون کامپایلشون کنید. اما اسکریپت هایی که خودتون به زبان PHP مینویسید همچنان تفسیر میشن. با این حال تفاوت سرعت بسیار بالاست. البته همین کدهای PHP که تفسیر میشن رو هم میشه با OPCache بهینه کرد.

[eshpilen]

ببین مهندس بالاخره نفهمیدم متوجه منظور من شدی و قبول داری یا نه.
JIT میتونه سرعت اجرا رو نسبت به دیگر روشهای اجرای bytecode بالاتر ببره، اما این امر به شرطی قطعی/قابل توجه میشه که دستوراتی در برنامه باشن که به تعداد زیاد تکرار میشن. حالا اون دستورات تکرار شونده هرچی تعدادشون و تعداد تکرارشون بیشتر باشه، طبیعتا افزایش سرعت بیشتر میشه.

در ویکیپدیا هم همینو میگه:

Some systems, called dynamic translators, or "just-in-time" (JIT) compilers, translate bytecode into machine language as necessary at runtime ... This introduces a delay before a program is run, when bytecode is compiled to native machine code, but improves execution speed considerably compared to direct interpretation of the source code—normally by several magnitudes

ترجمه: بعضی سیستمها، بنام مترجم دینامیک، یا کامپایلرهای JIT، در زمان اجرا درصورت نیاز bytecode را به زبان ماشین ترجمه میکنند ... این قبل از اینکه برنامه شروع به اجرا کند یک تاخیر ایجاد میکند (وقتیکه bytecode دارد به زبان ماشین محلی تبدیل میشود) اما سرعت اجرا را در مقایسه با تفسیر مستقیم کد منبع (م: اینجا مبهم گفته ولی منظورش درواقع بایت کد رو هم شامل میشه) به میزان قابل توجهی (معمولا چند برابر) بالا میبرد.

منبع: http://en.wikipedia.org/wiki/Bytecode

مهندس پس سرعت اجرا بالا میره. اون کد زبان ماشین توی دات نت داره با سرعت 3 برابر بایت کد PHP اجرا میشه. فرضا سرعت اجرای کد ماشین دات نت 0.01 ثانیه، و بایت کد PHP داره با سرعت 0.03 ثانیه تفسیر میشه، اما چون این زمانها هر دو بهرحال کوچک هستن و به چشم کاربران نمیان و سیستم زیر بار حداکثری هم نیست که کمبود منابع پیش بیاد، و چون مثلا عملیات کامپایل JIT خودش مثلا 0.1 ثانیه زمان صرف کرده (یعنی 10 برابر زمان اجرای کد ماشین صرف کامپایلش شده - البته این اعداد فقط یک مثال فرضیه و احتمال داره اغراق/اشتباه باشه)، در کل ما افزایش سرعت چندانی نداریم و حتی ممکنه سرعت دات نت در کل کمتر باشه بعلت پارامترها و تاخیرها و کندی در جاهای دیگر سیستم که JIT تنها یکی از اوناست. ولی برتری JIT بر تفسیر مستقیم موقعی مشخص میشه که توی برنامه پردازش قابل توجه و تکرار شونده به تعداد زیاد داشته باشیم؛ مثلا فرض کنیم اون کدها که در دات نت 0.01 ثانیه زمان صرف میکنن حالا توی یک حلقه for هستن و هزار بار تکرار میشن، در نتیجه زمان اجرا در کل میشه 10 ثانیه (0.01*1000)؛ و مال PHP چون 0.03 ثانیه بود میشه 30 ثانیه (0.03*1000). در اینطور موارده که افزایش سرعت مشاهده میشه.
بنچمارک هایی هم که خود میکروسافت و بعضیا انجام دادن و نشون دادن که سرعت دات نت بیشتره احتمالا بخاطر همین موارد بوده (حالا اینکه انتخاب چنین الگوریتم ها و برنامه هایی تا چه حد طبیعی و بی طرفانه بوده بماند). اما این موضوعی هست که خیلی ها نمیدونن یا بهش اشاره نمیکنن.
حالا اینکه در کل و از نظر میانگین سرعت اجرای برنامه های دات نت بیشتر باشه یا نه و چقدر بستگی به آمار و ساختار برنامه های استفاده شده در کل داره از نظر میانگین، و بعدش هم پارامترهای دیگری که لزوما بطور مستقیم به خود دات نت هم مربوط نمیشن (مثلا ممکنه خود ویندوز یا بخشهای دیگری از محیط کندتر از معادل اونا در لینوکس و PHP باشن و غیره). یه مسئله ای نیست که به این راحتی بشه از جوابش مطمئن شد. باید تحلیل و تحقیق و جمع آوری آمار بیشتری صورت بگیره و تجربی هم هست و نمیشه همه چیز رو بصورت تئوریک بقدر کافی دقیق و مطمئن محاسبه کرد.

[Mori Bone]

منظور شما اینه که php کامپایل میشه یانه که بله کامپایل میشه خروجیش html هست که توسط مرورگر دانلود و ترجمه میشه البته php

این حرف کاملا اشتباه است. مرورگر نمیاد php رو تفسیر و ترجمه کنه و به htnl تبدیل کنه. بلکه server این کدهای php رو تفسیر میکنه، اگه به دیتابیس احتتیاج بود به اون وصل میشه و دستورات رو در دستابیس اعمال می کنه و بعد در آخر html رو به مرورگر میفرسته و مررورگر طبق این html، صفحه بندی میکنه

[eshpilen]

میکروسافت و طراحان دات نت و اونایی که JIT رو اختراع و استفاده کردن اینقدر هم دیگه بیسواد نبودن که چنین اشتباه واضح و احمقانه ای بکنن بیان یک بار کامپایل کنن فقط و بعدش هم زمان اجرا هیچ تفاوتی نکنه چون زمان کامپایل خودش زمان اجرای کمتر کد ماشین رو تحت الشعاع قرار داده.
مسئلهء افزایش سرعت اینه که یک بار کامپایل میکنی، اما تا زمانی که اون پراسس فعاله و توی RAM در حال اجراست، عملیات با سرعت بیشتری اجرا میشه. اگر اون پراسس فقط برای یک دو کار کوچک و یکی دو بار بکار بره، افزایش سرعت محسوس نیست، ولی اگر بیاد و چند کار نسبتا سنگین پردازشی رو به دفعات زیادی انجام بده اونوقت افزایش سرعت میتونه محسوس بشه.
میتونیم بگیم در اکثر یا حداقل خیلی برنامه های وب عادی چون پردازش تکراری (حلقه وار) زیادی نداره و این پردازشها عمر کوتاهی دارن و فقط یک بار برای تولید خروجی یک درخواست و یک صفحه استفاده میشن، این افزایش سرعت عملا وجود نداره یا محسوس نیست. ولی اونجایی که عملیات تکراری زیادی داشته باشه یا مثلا برنامه بصورت یک سرویس و پردازش daemon ای چیزی عمل کنه (حداقل برای مدت محدودی و تعدادی درخواست سرویس) و برای مدتی در حال اجرا و سرویس دهی در RAM باقی بمونه، اونوقت اون افزایش سرعت میتونه محسوس بشه.

خلاصه توی برنامه های عادی و کلیشه ای که دوتا کانکشن دیتابیس میزنن و دوتا واکشی و درج ساده که این عملیات داخل حلقه نیستن یا بهرصورت تکرار زیادی ندارن و حجم و کار اعظم برنامه از اجرای یکسری دستورات خط به خط و متوالی تشکیل شده، ما افزایش سرعت رو مشاهده نمیکنیم. ولی توی برنامه هایی که عملیات داخلی با تکرار زیاد دارن یا طول عمر بیشتری دارن و یک کار سرویس دهی مجددی رو در این مدت انجام میدن، این افزایش سرعت میتونه دیده بشه. یعنی اینکه مثلا قطعه کد ماشین که از ترجمهء خط 10 برنامه تا خط 50 تولید شده هزار بار اجرا بشه، نه اینکه فقط یک بار یا چند بار معدود اجرا بشه. یک بار مصرف نباشه!

البته الان PHP با این سیستم های شتاب دهنده از انواع مختلف و کش و این حرفا هم فکر میکنم سرعت خوبی داشته باشه که نزدیک دات نت برسه حتی در چنین مواردی. ولی یجا اگر باشه که اون یه ذره افزایش پرفورمنس مهم باشه، اونوقت JIT گزینهء بهتری میشه.
بهرحال حالا که PHP عملا همه چیز داره. مثلا فیسبوک هم سیستم تبدیل به سی++ و کامپایل رو درست کرده. روی هاستهای اشتراکی هم که ملت همین سرعت و منابع اکثرا براشون کافیه دیگه!
بنده فقط خواستم به این قضیه اشاره و اون رو روشن کنم، چون ظاهرا خیلی ها ازش بی اطلاع هستن.

[MMSHFE]

درسته حرفهاتون رو من هم قبول دارم ولی یک نکته رو بد نیست یادمون نره اونم اینه که هدف مایکروسافت از کامپایل دومرحله ای و استفاده از JIT Compiler اصلاً سرعت و بهینگی نبوده بلکه امکان فراهم کردم Teamwork و حتی Multi-Platforming بوده که اولی رو موفق شده ولی در دومی هنوز کار خاصی نکرده و اگه هدفش سرعت بود خوب عین آدم میرفت کامپایل میکرد شر قضیه کنده میشد میرفت پی کارش.

[eshpilen]

JIT هربار میاد Bytecodeها رو یکی یکی اجرا میکنه
الان به این جمله شما دقت کردم دیدم اشکال یا ابهام داره.
JIT بر طبق تعریف، کدها یا بایت کدها رو خودش اجرا نمیکنه (اون میشه مثل PHP)، بلکه اونا رو به زبان ماشین کامپایل میکنه و بعد اون کدهای کامپایل شده خودشون بصورت مستقیم روی CPU اجرا میشن.
موضوع و فرق مهم در این دو نوع اجرا از همین ناشی میشه. اینکه در هر بار اجرای یک حلقه بایت کدها توسط یک مفسر یا ماشین مجازی اجرا بشن با اینکه در هر بار اجرای حلقه دستورات زبان ماشین کامپایل شده خودشون مستقیما اجرا بشن تفاوت میکنه. در JIT فقط بار اول JIT عمل میکنه و در بارهای دیگر در درون حلقه دستورات زبان ماشین خودشون مستقیما اجرا میشن.


عملاً چیزی به اسم کامپایل واقعی وجود نداره توی NET. و فقط یکبار در زمان Build پروژه است که کدها کامپایل و خطایابی میشن و اگه مشکلی نبود به MSIL تبدیل میشن.
یعنی میفرمایید JIT کامپایل نیست؟
JIT کامپایل است. چون طبق تعریف خودش صریحا گفته که کد زبان ماشین محلی تولید میکنه.
تنها فرق این کامپایل با کامپایل زبانهایی مثل سی++ اینه که کد زبان ماشین تولید شده توسط JIT عمر کوتاهی داره و فقط برای همون پراسس استفاده میشه و بصورت موقت در RAM وجود داره و با خاتمهء پراسس از بین میره.

[eshpilen]

هدف مایکروسافت از کامپایل دومرحله ای و استفاده از JIT Compiler اصلاً سرعت و بهینگی نبوده بلکه امکان فراهم کردم Teamwork و حتی Multi-Platforming بوده
برای Multi-Platforming که JIT ضرورت نداره. مگه PHP مالتی پلتفورم نیست؟ مگه جاوا نیست؟ تازه زبانهای دیگری هم هستن.
درمورد Teamwork هم متوجه نمیشم چه ربطی داره و دقیقا چرا برای Teamwork نیاز به JIT است! یعنی فقط زبانهایی که JIT دارن این Teamwork رو که شما میگید دارن؟


در دومی هنوز کار خاصی نکرده
شاید برای آیندهء خودش کرده. مثلا فکر کرده اگر سیستم عاملی جدیدی درست کرد یا مثلا برای پلتفورم سخت افزاری جدیدی، بتونه دات نت رو راحتتر به اون پورت کنه.
لزوما اینطور نیست که فکر کنیم حتما باید برای لینوکس و مک و غیره هم نسخه میداده یا همین الان این کار رو میکرده.
شایدم چنین قصدی داشتن ولی شرایطش تاحالا پیش نیامده و نیازها و بازار اونطور که اونا پیشبینی کردن نشده و خلاصه به هر دلیلی منصرف شدن.


اگه هدفش سرعت بود خوب عین آدم میرفت کامپایل میکرد شر قضیه کنده میشد میرفت پی کارش.
چیزی که واضحه اینه که تفسیر، JIT، و کامپایل معمولی هرکدام خواص و مزایا و معایبی دارن.
در این باره در مقالهء ویکیپدیا آمده که JIT بعضی از مزایا و همچنین معایب هردوی تفسیر و کامپایل معمولی رو داره.
شما میگی هدفش سرعت اگر بود، ولی معلوم نیست هدفش فقط سرعت بوده باشه، شاید یکسری مزایای دیگری رو هم میخواسته که در کامپایل معمولی نمیشد یا دشوارتر بود رسیدن بهشون.
در این مورد مقالهء ویکیپدیا بنظر میاد توضیحات کافی و همچنین مثالهایی داره که بنده دیگه الان وقت ندارم ولی اگر خواستید میخونیم و میذاریم و بررسی میکنیم.

[MMSHFE]

الان به این جمله شما دقت کردم دیدم اشکال یا ابهام داره.
JIT بر طبق تعریف، کدها یا بایت کدها رو خودش اجرا نمیکنه (اون میشه مثل PHP)، بلکه اونا رو به زبان ماشین کامپایل میکنه و بعد اون کدهای کامپایل شده خودشون بصورت مستقیم روی CPU اجرا میشن.
موضوع و فرق مهم در این دو نوع اجرا از همین ناشی میشه. اینکه در هر بار اجرای یک حلقه بایت کدها توسط یک مفسر یا ماشین مجازی اجرا بشن با اینکه در هر بار اجرای حلقه دستورات زبان ماشین کامپایل شده خودشون مستقیما اجرا بشن تفاوت میکنه. در JIT فقط بار اول JIT عمل میکنه و در بارهای دیگر در درون حلقه دستورات زبان ماشین خودشون مستقیما اجرا میشن.
موضوع همینجاست که طبق صحبت شما اگه توی هربار اجرا پردازش تکراری زیادی نداشته باشیم، هرچقدر هم پردازشها سنگین باشن تفاوت خاصی بین برنامه های مفسری و کامپایلی ایجاد نمیشه.

یعنی میفرمایید JIT کامپایل نیست؟
JIT کامپایل است. چون طبق تعریف خودش صریحا گفته که کد زبان ماشین محلی تولید میکنه.
تنها فرق این کامپایل با کامپایل زبانهایی مثل سی++ اینه که کد زبان ماشین تولید شده توسط JIT عمر کوتاهی داره و فقط برای همون پراسس استفاده میشه و بصورت موقت در RAM وجود داره و با خاتمهء پراسس از بین میره.
هست ولی همونطور که گفتم هربار اتفاق میفته یعنی اینکه اینطور نیست که یکبار کامپایل کنه و Native Code ساخته بشه و دیگه JIT بره کنار.

برای Multi-Platforming که JIT ضرورت نداره. مگه PHP مالتی پلتفورم نیست؟ مگه جاوا نیست؟ تازه زبانهای دیگری هم هستن.
درمورد Teamwork هم متوجه نمیشم چه ربطی داره و دقیقا چرا برای Teamwork نیاز به JIT است! یعنی فقط زبانهایی که JIT دارن این Teamwork رو که شما میگید دارن؟
یکی از راههای Multi-Platforming همین دومرحله ای کردن کامپایله که جاوا هم همینکار رو میکنه و JVM که نصب میشه بخاطر همین مسئله است که بیاد کدهای واسط رو تبدیل کنه به زبان ماشین مربوطه و البته Platform فقط شامل سیستم عامل نیست و سخت افزار رو هم شامل میشه. بخاطر همینه که حتی با وجود کامپایل کدهای Java برای لینوکس و ویندوز باز هم برای اجرا به ماشین مجازی جاوا احتیاجه. PHP هم که کلاً تفسیریه و بحثش جداست و مفسر PHP برای پلتفرمهای مختلف میاد کد ماشین رو همون لحظه تولید میکنه.
درمورد تیم ورک هم مایکروسافت اومد همه کدهای تولیدشده با هر زبان تحت NET. رو به زبان واسط تبدیل کرد تا به راحتی بتونن توی برنامه، کلاسهای همدیگه رو صدا بزنن. مثلاً توی یک پروژه شما ممکنه با #C کد بنویسید و جایی نیاز باشه کدی که هم تیمی شما با VB.NET نوشته رو بکار ببرین و یکی از کلاسهاش رو مورد دسترسی قرار بدین. اینجا اگه زبان مشترکی وجود نداشته باشه نمیتونید چنین کاری انجام بدین. بخاطر همین دوستتون میاد کدش رو کامپایل میکنه به زبان واسط و شما توی پروژه ازش استفاده میکنید. اصلاً بخاطر همین هم هست که کدهای کامپایل شده NET. راحت Decompile میشن چون اگه نمیشد بخشهای مختلف کد که با زبانهای مختلف نوشته شدن نمیتونستن با هم ارتباط برقرار کنن. فقط زبانهای دارای JIT تیم ورک ندارن ولی فرضاً شما نمیتونید بین Java و PHP رابطه مستقیمی برقرار کنید چون زبان مشترکی بینشون نیست. مگه اینکه اطلاعات رو با یک ساختار مشترک دیگه مثل JSON و... مبادله کنید که قطعاً کارآیی اون به اندازه به اشتراک گذاشتن خود کلاسها و اشیاء نخواهد بود.

شاید برای آیندهء خودش کرده. مثلا فکر کرده اگر سیستم عاملی جدیدی درست کرد یا مثلا برای پلتفورم سخت افزاری جدیدی، بتونه دات نت رو راحتتر به اون پورت کنه.
لزوما اینطور نیست که فکر کنیم حتما باید برای لینوکس و مک و غیره هم نسخه میداده یا همین الان این کار رو میکرده.
شایدم چنین قصدی داشتن ولی شرایطش تاحالا پیش نیامده و نیازها و بازار اونطور که اونا پیشبینی کردن نشده و خلاصه به هر دلیلی منصرف شدن.
همه این شایدها رو ما هم میدونیم ولی چیزی که در عمل اتفاق افتاده اینه که تا الان اونطور که باید از JIT استفاده بهینه نکرده مایکروسافت. هیچ کاری به سیاستهای مایکروسافت و اینکه چقدر موفق بوده ندارم چون ربطی به موضوع بحث نداره و فقط خواستم بگم چنین چیزی هم وجود داره و ابهامی که برخی دارن و فکر میکنن NET. بخاطر کامپایلی بودنش سریعتره (که توی خیلی از مستندات علمی! ما هم متأسفانه قید میشه) آنچنان پایه و اساس درستی نداره.

چیزی که واضحه اینه که تفسیر، JIT، و کامپایل معمولی هرکدام خواص و مزایا و معایبی دارن.
در این باره در مقالهء ویکیپدیا آمده که JIT بعضی از مزایا و همچنین معایب هردوی تفسیر و کامپایل معمولی رو داره.
شما میگی هدفش سرعت اگر بود، ولی معلوم نیست هدفش فقط سرعت بوده باشه، شاید یکسری مزایای دیگری رو هم میخواسته که در کامپایل معمولی نمیشد یا دشوارتر بود رسیدن بهشون.
در این مورد مقالهء ویکیپدیا بنظر میاد توضیحات کافی و همچنین مثالهایی داره که بنده دیگه الان وقت ندارم ولی اگر خواستید میخونیم و میذاریم و بررسی میکنیم.
من هم همین رو گفتم و اشاره کردم که مایکروسافت هدفش سرعت نبوده اینجا و این رو توی کنفرانسهای خبری خودشون هم اعلام کردن. پس ما هم نباید از این قابلیت کامپایلی بودن کدهای NET. بعنوان عامل سرعت یاد کنیم.

[eshpilen]

مفسر PHP برای پلتفرمهای مختلف میاد کد ماشین رو همون لحظه تولید میکنه.
کد ماشین تولید میکنه؟!
تاجاییکه میدونم تفسیر همچین چیزی نیست. هیچ کد ماشین جدیدی از اجرای یک اسکریپت PHP تولید نمیشه! اگر بشه، این خودش میشه یک نوع کامپایل و همون JIT و این حرفا.
منبع و دلیل شما برای این ادعا چیه؟ شایدم منظورتون یه چیز دیگه بود!


ابهامی که برخی دارن و فکر میکنن NET. بخاطر کامپایلی بودنش سریعتره (که توی خیلی از مستندات علمی! ما هم متأسفانه قید میشه) آنچنان پایه و اساس درستی نداره.

میتونه در خیلی موارد سریعتر باشه. ولی همونطور که گفتم این بستگی به ساختار و الگوریتم های برنامه داره و عامل مهم تکرار.
و به گمانم در بیشتر برنامه های وب عادی این شرایط به اون صورت که افزایش سرعت رو قابل توجه بکنه و پارامترهای دیگر رو تحت الشعاع قرار بده وجود نداره.
ولی بهرحال بنده فکر میکنم دات نت میشه گفت یک فناوری ای هست که برای بیس وسیعتری از چیزی که PHP داره طراحی شده. از برنامه های دسکتاپ تا وب و از سرویس دهنده تا کلاینت از مقیاس کوچک تا بزرگ. شاید در 80% از وب موجود اون مزایا به کار نیان، و از طرف دیگر کم و بیش انحصاری بودن و محدود بودنش به پلتفرم میکروسافت هم باعث شده که در وب PHP سهم خیلی بیشتری داشته باشه. ولی به هیچ وجه نمیشه دات نت رو دست کم گرفت، چون طراحی اون از نظر فنی هدف گسترده تری داشته و از سیستم پیشرفته تری که انعطاف زیادی بهش میده (که برای این هدف گسترده مورد نیازه ولی اگر بحث فقط برنامه نویسی وب بود نیاز خیلی کمتری بهش بود) استفاده میکنه. همونطور که جاوا باوجود گسترده و پیشرفته بودنش و طراحی اصولی که از ابتدا داشته با این حال رقیب جدی برای PHP در وب عادی نشد و فقط در برنامه ها و مقیاس های خاصی بیشتر استفاده میشه، دات نت هم به همین شکل رقابت مستقیم کمتری با PHP داره و مزایاش بیشتر در موارد و مقیاس های خاصی مشخص میشن.

[MMSHFE]

منظورم اینه که کد زبان PHP رو میخونه و Instruction مناسب رو به پردازنده میده که قاعدتاً این دستورات به زبان ماشین هستن.
درمورد کاربرد NET. هم حق با شماست و هدفش کلاً فرق میکنه. برای مثال امکاناتی که Sharepoint در اختیار قرار میده برای پورتالهای سازمانی خیلی خوبه (مثلاً یک نفر بتونه با ابزارهای دم دستی مثل Office بیاد برای پورتال سازمانی مربوطه بدون دانش برنامه نویسی، فرم تولید کنه یا اطلاعات وب سایت به محض دریافت به شکل مناسب توی Excel و... قابل دریافت باشن بصورت لوکال و کلی امکانات دیگه که این موارد که اشاره کردم، کوچکترین اونهاست). صحبت من اصلاً چیز دیگه بود و اونم اینکه بخوایم ازنظر سرعت مبنای کار رو روی کامپایلی بودن بگذاریم از اساس اشتباهه و قیاس مع الفارقه. مثل اینه که بیایم موتور تریلی 18 چرخ رو ازنظر سرعت با لامبورگینی مقایسه کنیم درحالی که اساساً موتور تریلی برای قدرت و زور زیاد طراحی شده. منظورم اینه که فاکتور مقایسه نباید سرعت باشه حتی اگه تریلی 18 چرخ توی شرایط خاصی از لامبورگینی جلو بزنه.

[MMSHFE]

راستی حالا که بحث تا اینجا پیش رفته بد نیست یه نگاهی به PHP Gearman (http://php.net/manual/en/intro.gearman.php) بندازین. احساس میکنم یه جورایی امکانات خاص PHP از دید خیلی از حرفه ایهای این عرصه هم تو کشور ما پنهان مونده و باعث میشه تو خیلی موارد از موضع ضعف توی مقایسه ها وارد بشیم.

[MMSHFE]

البته ASP از فریمورک .net استفاده میکنه که شرایط خاصی رو روی سرورها میطلبه. برنامه نویسان PHP هم اگر بهینه سازی ها براشون مهمه و سایتی دارند که نیاز به سرعت بالا داره از فریمورک phalconphp (http://phalconphp.com/en/)استفاده کنند تا بهترین نتیجه رو حاصل کنند. به هر حال phalconphp هم مثل .net یک فریمورک محسوب میشه برای زبان برنامه نویسی PHP.
البته فایل های خود فریمورک بوسیله ی C نوشته شدن و کامپایل شده هستند یا میتونید روی سرورهای لینوکس خودتون کامپایلشون کنید. اما اسکریپت هایی که خودتون به زبان PHP مینویسید همچنان تفسیر میشن. با این حال تفاوت سرعت بسیار بالاست. البته همین کدهای PHP که تفسیر میشن رو هم میشه با OPCache بهینه کرد.

البته یک نکته هم اینجا لازمه اضافه بشه و اونم اینکه سرعت فریمورکها هرچقدر هم که بالا باشه (حتی فالکون که با C نوشته شده) از سرعت PHP خام کمتره و هدف فریمورکها بالابردن سرعت Develop هست نه بهینه سازی سرعت زمان اجرای اسکریپت.

[eshpilen]

منظورم اینه که کد زبان PHP رو میخونه و Instruction مناسب رو به پردازنده میده که قاعدتاً این دستورات به زبان ماشین هستن.
این درست تر شد اما فکر میکنم هنوزم ممکنه برای مبتدی ها ابهام ایجاد کنه. یعنی فکر میکنن مفسر میاد و خودش مستقیما دستورات زبان ماشین رو یجوری میسازه و دونه به دونه به خورد CPU میده. اما تاجاییکه بنده میدونم اساس کار مفسر ساده تر از این حرفهاست.
ما یه برنامه مینویسیم که ورودی هاش رو از کاربر میگیره و بر اساس اونا کار انجام میده. مثلا دو عدد رو میگیره و جمع میکنه (یا عملیات مورد نظر رو هم ما ممکنه از طریق پارامتر دیگری بهش بدیم) و جواب رو ارائه میده. برنامه اینجا صرفا ورودی های کاربر رو در دو متغییر خودش که مخصوص این کاره میذاره و عملیات مورد نظر رو هم بوسیلهء یک دستور شرط یا switch و اینها انجام میده. حالا فرض کنیم بجای اینکه کاربر مستقیما ورودی بده، دو عدد و عملیاتی که میخواد رو توی یک فایل ذخیره کرده باشه که برنامه میاد و فایل رو parse میکنه، دو عدد و عملیات مربوطه رو از توش جدا میکنه، اونا رو توی متغییرهای مربوطه میذاره و بعد اجرا میکنه. این میشه مثل یک مفسر خیلی ساده! غیر از اینه؟
ما در این مفسر کاری جز parse کردن و قراردادن مقادیر کاربر در متغییرهایی که از پیش در برنامه تعریف شدن نداشتیم. کدماشین جدیدی هم به اون معنا تولید نمیشه، بلکه چیزی که اتفاق میفته فقط اینه که کد ماشینی که از قبل در برنامه موجوده و کامپایل شده با پارامترهای کاربر اجرا میشه. حالا این مفسر میتونه از این خیلی گسترده تر و پیچیده تر باشه و کارهای بیشتری بکنه، و ورودیش میتونه بجای عدد و عملیات ریاضی حتی یک برنامه باشه! اونوقت اون میشه مفسر زبان برنامه نویسی. غیر از اینه؟
برای مثال وقتی در یک برنامهء PHP دستورات باز کردن یک فایل هست، PHP نام فایل مورد نظر برنامه نویس رو از داخل فایل سورس میخونه و بعنوان آرگومان به روتین باز کردن فایل خودش میده. همینطور دستورات دیگر نوشتن در فایل و غیره. پس این وسط فقط پارامترها هستن که متغییرن و هیچ کد ماشین جدیدی نیازی نیست که تولید بشه یا PHP خودش بطور مستقیم در سطح کد ماشین فکر یا کاری بکنه.
البته باز کردن و نوشتن در فایل یک کار ساده بود، انجام عملیات ریاضی هم همینطور؛ اینقدر ساده که خود ما نسبتا براحتی و در زمان کمی میتونیم مفسرهای محدودی برای انجام چنین کارهایی رو در هر زبانی بنویسیم. اما عملیات دیگر هم اساسا چیز متفاوتی نیستن، گرچه طبیعتا پیچیده تر هستن و نیاز به الگوریتم های تخصصی و پیشرفته ای دارن. مثلا اجرای دستورات دیگر مثل حلقه ها و غیره و خلاصه کل یک زبان با این همه دستورات و ترکیبات و پیچیدگی هاش.
بهرحال هر کاری که برنامهء ما میخواد انجام بده و در زبان PHP دستورش هست باید از قبلش خود مفسر PHP چنان روتین و کاری رو در خودش تعریف شده داشته باشه که بعد با پارامترهای برنامهء ما اجراش کنه. تمام کدهای ماشین برای انجام تمام دستورات و توابع یک زبان از قبل در مفسر (یا اکستنشن ها و کتابخانه های مورد استفاده اون) زبان موجود و به زبان ماشین کامپایل شده هستند.

بنده این توضیحات رو دادم چون فکر میکنم بیان شما تاحدی مبهم و گمراه کننده بود و خیلی ها هم از طرز کار مفسرها اطلاع خاص و موثقی ندارن. ضمنا بنده قبلا کد و طرز کار یک مفسر خیلی ساده برای زبان basic رو دیده بودم (در کتاب C جفرنژاد قمی) که واقعا حجم و پیچیدگی زیادی هم نداشت. در سطح مفسر ما هیچ کاری با کد ماشین نداریم و در نهایت صرفا همون دستورات و الگوریتم کد منبع برنامهء مفسر در زبانهای سطح بالا هست که با پارامترهای متغییر فراخوانی و اجرا میشن. میتونیم بگیم که مفسر بعنوان نماینده از جانب برنامهء ما، تمام عملیات رو مستقیما خودش انجام میده.

[MMSHFE]

البته دوست عزیز، PHP رو بهتره با مفسر BASIC کتاب جعفرنژاد قمی در یک سطح قرار ندین. PHP درسته که تفسیریه ولی مستقیماً با ماشین در ارتباطه وگرنه باید یک کامپایلر ++C هم در کنارش میبود که برنامه تفسیر شده رو بصورت Instructionها به خورد اون میداد. بخشهای مثل سیستم کش و مدیریت سشن و... PHP رو از یک مفسر ساده فراتر میبره. خوشبختانه PHP یک زبان Open Source هست و با بررسی سورس کدش متوجه میشین که در نهایت دستورات رو خودش به CPU ارائه میکنه و نیومدن یک پوسته برای ++C درست کنن.

[eshpilen]

آقا شما چرا قضیه رو میپیچونی و مدام ابهام درست میکنی؟
مستقیما با ماشین در ارتباطه یعنی چی دقیقا؟
خب اون مفسر basic هم در کتاب جعفر نژاد قمی با زبان سی نوشته شده بود و به زبان ماشین کامپایل میشه و مستقیما با ماشین در ارتباطه!! البته اگر منظور اینه که خودش از کدهای ماشین تشکیل شده و مستقیما روی CPU اجرا میشه و برنامهء شما رو هم اجرا میکنه.
من اصول و اساس کار مفسرها رو گفتم، که فکر نمیکنم PHP هم از این امر مستثنی باشه.
شما این رو قبول دارید یا نه؟
من میخوام روشن کنم که یک مفسر در اساس خودش چطور کار میکنه و در سطح کد ماشین چیزی رو تولید و تفسیر نمیکنه. حالا سیستمهای جانبی و ایناش رو کاری نداریم، ولی اونا هم بهرحال توسط خود مفسر پیاده سازی و اجرا میشن و در سطح زبان مورد نظر صرفا شبیه سازی شدن (منظورم اینه که مثلا کدهای سورس PHP خودشون بطور مستقیم به دستور و سیستم خاصی و جدید و مستقلی تبدیل نمیشن و هرچی و هر سیستم و امکاناتی که در زبان هست درون همون مفسر قبلا پیاده سازی شده و کدهای منبع ما فقط از اون سیستمها استفاده میکنن و بعنوان پارامترهایی براشون عمل میکنن).
بیان های شما خیلی ابهام آور و گمراه کننده هستن نمیدونم چرا! یکی دو مورد خودتون بعد از مطرح شدن توسط بنده اصلاح کردید.
منم نگفتم که اون مفسر ساده بیسیک با مفسر PHP یکیه. فقط خواستم بگم اصول و اساس کارشون در نهایت مشابه هست.

[MMSHFE]

گیج نشو برادر من. بجای این کارها سورس PHP و مستندات devzone.zend.com رو مطالعه کن:

A very high level and not necessarily complete overview of the process:


The source code is tokenized, i.e. it is broken down into individual parts and these parts are "classified". $str1 is a variable, = is an operator, "Hello world!" is a string literal, ; is a statement terminator etc.
The tokens are transformed into an abstract syntax tree (http://en.wikipedia.org/wiki/Abstract_syntax_tree), i.e. the tokens are "grouped by meaning". Something like we have an expression with the = assignment operator whose first operand is $str1 and whose second operand is the string literal "Hello world!".
These two steps complete the parsing.

The individual parts in the syntax tree are translated into low-level machine instructions, e.g. reserve some memory to store "Hello world!" and create a symbol $str1 to reference it.
That description is still pretty high level for "machine instructions" BTW and I just use it here to keep it simple.
This is basically the compilation step.

The instructions are executed.

The distinction between "interpreted" languages and "compiled" languages are somewhat arbitrary. Any language needs to be parsed and then translated into machine instructions, which is basically compilation. "Real" compiled languages must be compiled into a binary executable first which is then manually executed. PHP basically does both in one go, but then throws the executable code away. That's essentially what interpreted code is; it's parsed and compiled on the fly right from the source. There are byte code caches for PHP which cache the machine code, not requiring PHP to re-compile the same code over and over.
"Real" compilers also serve other purposes: they can often detect basic or even pretty complex problems during compilation by analyzing the code and then refuse to compile it; since PHP is winging it as it goes along it cannot catch these kinds of problems during compilation and they will crop up while code is already executing, which requires a different kind of error handling philosophy than compiled languages do. "Real" compilers can also spend more time on optimizing code and potentially make it execute faster; since PHP does it on the fly it doesn't spend much if any time on optimizing code, since this would make it even slower.
BTW, PHP as a language is neither interpreted nor compiled. It's just a language. The standard, official PHP runtime environment is what's interpreting the language. There are also PHP compilers, most famously Facebook's HipHop, which compile PHP code into executable binaries.

[eshpilen]

خب حالا شد یه چیزی. ولی لینک دقیق صفحه ای که این متن رو ازش درآوردی رو هم بذار تا اگر سرنخ ها یا مطالب مرتبط دیگری درش هست بررسی کنیم.
ضمنا حالا تفسیر خود شما از این متن چیه؟
این در پایان میگه PHP نه تفسیری است و نه کامپایلی. از طرف دیگه توضیحاتی که داده انگار داره همون JIT رو توضیح میده!!
منم اگر مفسر رو توضیح دادم اشتباه نکردم، چون تعریف مفسر عموما اینه و تاحالا همه میگفتن و همه جا نوشته که PHP یک زبان تفسیری است و مفسر داره.
حالا با این اوصاف بالاخره چی شد! شما که خودتون میگفتید JIT که دات نت داره کار بیهوده ایه چون هر بار کامپایل میکنه و بعد از اجرا دور میندازه، اما حالا میبینیم که PHP هم شاید کم و بیش مشابه همین کار رو انجام میده. البته طبق این متن. این متن هم مقداری ابهام داره و دقیقا تکلیف رو مشخص نکرده. گفته بین کامپایل و تفسیر، و به تبدیل به کد ماشین اشاره کرده، که البته JIT هم کم و بیش همینه! بهتر بود اشاره ای به JIT هم میکرد و توضیح میداد که فرق مدل PHP با JIT چیه که این سردرگمی پیش نیاد.

[MMSHFE]

خسته شدیا :چشمک:
فرق JIT با مفسر PHP اینه که JIT کدهای واسط رو تبدیل میکنه که یکبار قبلش کامپایل و به همون opcodeها یا بعضاً bytecodeها تبدیل شدن ولی PHP هربار خود متن خام برنامه رو تفسیر میکنه و مستقیماً به دستورات زبان ماشین تبدیل میکنه.

[eshpilen]

خسته شدیا :چشمک:
من خستگی ناپذیرم. فقط وقت ندارم و بخاطر همین عجله میکنم. همین بحثها رو هم سر کار و بعضا در حضور کارفرما انجام میدم :لبخند:
خدا بهتون رحم میکرد اگر بیکار بودم :چشمک:
شما فکر میکنی من اینا رو نمیدونم، ولی قبلا کلی مقاله راجع به هرچی فکرش رو بکنی خوندم و خیلی چیزا میدونم. کلیتش توی ذهنم هست و تمام حالات ممکن، ولی جزییات یادم نیست و برای بیان دقیق و مطمئن باید بازم رجوع و مرور کنم که وقت و سر خلوت میخواد.
همین JIT هم دیروز مقالهء ویکیپدیا رو کامل خوندم دیدم خیلی فراتر از اون چیزی که شما گفتی امکانات و انواع داره و انعطاف و چیزهای جالبی درش هست (که البته خیلی مواردش به فکر خودم هم رسیده بود که بعضیا رو قبلا اشاره کردم و بعضی موارد رو هم خیر). توی فکر بودم سر فرصت بخشی از اون رو ترجمه کنم و توی یک تاپیک جداگانه بذارم.

فرق JIT با مفسر PHP اینه که JIT کدهای واسط رو تبدیل میکنه که یکبار قبلش کامپایل و به همون opcodeها یا بعضاً bytecodeها تبدیل شدن ولی PHP هربار خود متن خام برنامه رو تفسیر میکنه و مستقیماً به دستورات زبان ماشین تبدیل میکنه.

خب اینطور که شما میگی که JIT یک قدم جلوتر از مفسر PHP است و باید سرعتش بیشتر باشه پس!
ضمنا شما از JIT دات نت ایراد میگرفتی میگفتی هر بار کامپایل انجام میده و کار بیهوده ایه و این حرفا، حالا فرق PHP با دات نت چیه پس در این زمینه؟

[MMSHFE]

ببین دوست عزیز، JIT باید هربار یکسری opcode رو تبدیل به زبان ماشین کنه (مثلاً بیاد مثل Assembly بگه هرجا mov ah,100 دیدی برو دستور 0100110000000100 رو اجرا کن) و مفسر PHP بجای اینکار مستقیماً وقتی دستور $x = 100; رو میبینه دستور 0100110000000100 رو به پردازنده ارسال میکنه. پس از این نظر تفاوتی در سرعت نیست. حالا JIT یک مرحله کامپایل قبلش داره که کدها رو از زبان برنامه نویسی تبدیل کرده به opcodeها و تنها امتیازش هم اینه که خطایابی شده و البته الان این opcodeها دیگه فرقی ندارن که با #C نوشته شدن یا VB.NET و بخاطر اینکه همه با زبان واحد حرف میزنن، به منابع و توابع هم دسترسی دارن. اما ازنظر سرعت اجرا تفاوت خاصی بینشون نیست.
من از دات نت ایراد نگرفتم که گفتم JIT هربار کامپایل میکنه و اصلاً هم هیچ جا نگفتم کار بیهوده ایه. گفتم هدفش سرعت نبوده و ایجاد سازگاری و... بوده و در بخش دوم که Multi-platforming بوده نتونسته کاری انجام بده. خواستم فقط بگم NET. هم هربار تفسیر رو در عمل داره و ملت از این خیال باطل که کدهای NET. کاملاً کامپایلی هستن بیان بیرون وگرنه مشکلی با تفسیری بودن PHP ندارم و همه جا هم مثل مرد گفته کامپایل نمیکنه کدها رو :چشمک:
شما الان سرعت اجرای کدهای ++C رو با #C یکی میدونی؟ کدهای Delphi ازنظر سرعت اجرا بالاتر از کدهای VB.NET نیستن؟ هستن دیگه. علتش هم واضحه: ++C و Delphi مستقیماً Native Code تولید میکنن. حالا بقول شما JIT هم اگه توش کش کردن و این چیزا نباشه (که تا جایی که بررسی کردم نبوده)، فرقی با PHP نداره. PHP هم با APC میتونه opcodeها رو برای اون مرحله اجرا کش کنه و با OPCache هم میتونه کلاً بیخیال Parse کردن مجدد اسکریپت بشه.
همین و بس.

[eshpilen]

ببین دوست عزیز، JIT باید هربار یکسری opcode رو تبدیل به زبان ماشین کنه
فکر منم منظور شما bytecode بود. چون مثل اینکه opcode بیشتر به همون دستورات زبان ماشین میگن.


مفسر PHP بجای اینکار مستقیماً وقتی دستور $x = 100; رو میبینه دستور 0100110000000100 رو به پردازنده ارسال میکنه.
فکر نکنم اینطور باشه. PHP هم اول به بایت کد خودش تبدیل میکنه و بعد اجرا میکنه.
در بحث شتاب دهنده ها و اینها هم که صراحتا نوشته شده اون bytecode رو (که یکجور ساختار داخلی و بهینه شده دستورات در سطح PHP است) کش میکنن و بخاطر همین بعدش هنوزم به مفسر PHP برای اجراش نیازه.


من از دات نت ایراد نگرفتم که گفتم JIT هربار کامپایل میکنه و اصلاً هم هیچ جا نگفتم کار بیهوده ایه. گفتم هدفش سرعت نبوده و ایجاد سازگاری و... بوده و در بخش دوم که Multi-platforming بوده نتونسته کاری انجام بده.
از کجا مطمئنید هدفش سرعت نبوده؟
من نمیگم تنها هدفش سرعت بوده یا اینکه سرعت اولویت اصلی/اولش بوده، ولی بهرحال JIT ها بطور معمول یکی از اهدافشون سرعته یا اصلا هدف اصلیشون در خیلی موارد رسیدن به سرعت بیشتری نسبت به مفسرهاست، و در عمل هم این افزایش سرعت باید وجود داشته باشه و طبیعی است؛ دلیلی نداره مثلا خودشون بیان جلوی سرعتش رو بگیرن بگن این هدفمون نبوده!!


خواستم فقط بگم NET. هم هربار تفسیر رو در عمل داره و ملت از این خیال باطل که کدهای NET. کاملاً کامپایلی هستن بیان بیرون وگرنه مشکلی با تفسیری بودن PHP ندارم و همه جا هم مثل مرد گفته کامپایل نمیکنه کدها رو :چشمک:
قبلا بحث کردیم و شما هم قبول کردید که درصورتیکه عنصر تکرار دستورات رو در برنامه به مقدار زیاد داشته باشیم، سرعت هم افزایش پیدا میکنه. ولی در وب این زیاد پیش نمیاد و حجم و تعداد بار اینطور کدها معمولا کمه.


شما الان سرعت اجرای کدهای ++C رو با #C یکی میدونی؟ کدهای Delphi ازنظر سرعت اجرا بالاتر از کدهای VB.NET نیستن؟ هستن دیگه. علتش هم واضحه: ++C و Delphi مستقیماً Native Code تولید میکنن.
خب این یه بحث دیگه هست. چه ربطی به مقایسهء مفسر و JIT داره.
البته با اون متنی که شما گذاشتی بالاخره نفهمیدیم که PHP دقیقا چطور کار میکنه؛ خودش گفته بین مفسر و کامپایل! توضیحاتی هم که داده تا حد زیادی شبیه JIT است ولی دقیق و قاطع مشخص نیست بالاخره چطوریه. مبهمه خلاصه. شما هم که جواب سوالات بنده رو در این ارتباط ندادید.


حالا بقول شما JIT هم اگه توش کش کردن و این چیزا نباشه (که تا جایی که بررسی کردم نبوده)، فرقی با PHP نداره. PHP هم با APC میتونه opcodeها رو برای اون مرحله اجرا کش کنه و با OPCache هم میتونه کلاً بیخیال Parse کردن مجدد اسکریپت بشه.
همین و بس.
شما چرا مدام میگی opcode؟
مثل اینکه جامون رو عوض کردیم :لبخند:
خود APC داره میگه من bytecode رو کش میکنم، بعد شما میگی opcode؟!

[eshpilen]

و هربار هم چک کنه ببینه کش هنوز معتبره یا نه.
مهندس این حرف رو چند بار به شکل کم و بیش مشابهی بیان کردی.
من نمیدونم قضیهء این چک کردن اعتبار کش چیه و چرا بنظر شما اینقدر مشکل و هزینه بره که بعنوان یک ایراد ذکر میکنیش!
یه چک کردن اعتبار که چیزی نیست. در خیلی موارد با یک چک کردن ساده تاریخ Modified فایل میتونه انجام بشه که این هم از جمله کوچکترین و ساده ترین و سریعترین عملیاتی هست که در بین این همه عملیات روی یک چنین سیستمهایی انجام میشه. انجام چنین کاری حتی روی چند هزار entry هم امروزه کار چندان بزرگ و زمانبری بحساب نمیاد.
ضمنا در تاپیکی که الان درمورد JIT زدم (http://barnamenevis.org/showthread.php?468178) و مطالبی درج کردم میبینیم که سیستمهای JIT که قبلا توسط دیگران (مثل ماشین مجازی سان برای جاوا) هم طراحی و پیاده سازی شدن چه سیستمهای هوشمند و گسترده ای دارن و در زمان اجرا کلی چیزها و حتی تعداد فراخوانی توابع برنامه رو تحت نظر میگیرن و خیلی کارهای جانبی دیگه، که حساب کنی اینا باید از یک چک کردن اعتبار کش، عملیاتی پیچیده تر و زمانبرتر باشن در کل (حالا چه کش موقتی در RAM و برای همون اجرای خاص یک برنامه باشه و چه کش در سطوح دیگری و مثلا کش در سطح سیستم فایل) و با این وجود بازم این همه چک و عملیات و الگوریتم و محاسبه و پیشبینی به هزینه هاش میصرفیده و سرعت رو بالا میبرده (حداقل در سناریوهای مورد نظر) که اونا رو گذاشتن. غیر از اینه؟