من المترجم: أصبحت مشكلة البرامج البطيئة واحدة من الموضوعات الرئيسية للمناقشة حول Habré و Hacker News في الأسابيع الأخيرة. على سبيل المثال ، راجع مقالة نيكيتا بروكوبوف "خيبة أملي في البرامج" و 2432 تعليقًا عليها.

نقضي الكثير من الوقت على الكمبيوتر. نحن ننتظر في كل مرة تقوم فيها بتشغيل التطبيقات وتحميل صفحات الويب. في كل مكان توجد رموز الدوار أو الساعة الرملية. أصبح الحديد أكثر قوة ، لكن البرامج لا تزال تبدو بطيئة. لماذا هذا

إذا كنت تستخدم جهاز كمبيوتر للقيام بعمل هام ، فأنت تستحق برامج سريعة. في كثير من الأحيان ، لا تلبي البرامج الحديثة هذه المتطلبات. في مختبر أبحاث Ink & Switch ، درسنا أسباب هذا الموقف ، وتحسن البرنامج في النهاية. نشرت هذه المقالة نتائج دراستنا.

جدول المحتويات

• أين البطء بالضبط
  
  • التأخير ليس عرض النطاق الترددي
  • واجهات اللمس
  • لوحة المفاتيح
  • فأر
  • التطبيقات
• من أين يأتي التباطؤ؟
  
  • جهاز الإدخال
  • معدل أخذ العينات
  • يعرض ووحدات معالجة الرسومات
  • تراكب حلقة
  • وقت التشغيل العلوي
  • تأخير متعمد
  • وكلاء معادية
  • كود التطبيق
  • ضع كل ذلك معًا
• لبرمجيات سريعة
• الأدب

أين البطء بالضبط

ما الذي يعتبره المستخدمون برنامجًا "بطيئًا"؟ في بعض الأحيان تزعج البرامج جميعنا بالتأخير والتأخير. ولكن من أجل فهم هذه المشاكل بشكل أفضل ، يجب استكمال الأحاسيس البديهية بالدراسات الأكاديمية التي تجيب بدقة على هذا السؤال.

ترتبط السرعة المدركة ارتباطًا وثيقًا بمفهوم الكمون. توضح مقارنة البحث العلمي حول "ما يبدو بطيئًا" مع قياس التأخير الحقيقي في هذه التطبيقات مدى سوء كل شيء.

التأخير ليس عرض النطاق الترددي

عند مناقشة أداء البرنامج ، غالبًا ما نسمع عن النطاق الترددي. على سبيل المثال ، "يمكن لخادم الويب هذا تنفيذ 10000 طلب في الثانية." لكن هذه ليست الطريقة التي يدرك بها المستخدمون الأشياء. يهتمون بالوقت الذي يستغرقه طلب الويب الخاص بهم أو الوقت المستغرق لفتح مستند ، أو مدى سرعة استجابة التطبيق للنقرة بالماوس. ترتبط هذه التفاعلات مع الكمون. التأخير هو مقياس مهم سنقوم بدراسته في هذه المقالة.

تصور المستخدم
لمزيد من المعلومات حول أهمية الكمون في الأنظمة التفاعلية ، انظر هنا .

عوامل أخرى تؤثر على الشعور بسرعة البرمجيات. على سبيل المثال ، معدل الإطار وردود الفعل خلال المهام الطويلة. لكننا نعتقد أن الكمون مقياس أساسي ، ومع الكمون المنخفض جدًا ، فإن أي برنامج سيشعر بسرعة كبيرة.

واجهات اللمس

أولاً ، ضع في الاعتبار الحساسية البشرية لتأخيرات الشاشة التي تعمل باللمس.

يتحقق الباحثون من ذلك من خلال اختبارات تحدد بالضبط ما الذي يؤخره المستخدمون. أولاً ، يتم عرض الموضوعات على واجهة لها (تقول) تأخيرًا يبلغ 1 مللي ثانية ، ثم (تقول) 70 مللي ثانية ، ويُطلب منها تنفيذ عمليات مثل الضغط على زر. إذا كانت واجهة 70 مللي ثانية تظهر باستمرار نتائج أسوأ من واجهة 1 مللي ثانية ، فإن 70 مللي ثانية تسمى "الفرق الملحوظ".

أقل فرق ملحوظ
لمزيد من التفاصيل حول الحد الأدنى من الاختلاف الملحوظ في التأخير والمرافق التجريبية ذات الصلة ، انظر ، على سبيل المثال ، هذا العمل .

الحد الأدنى الملحوظ هو الميزانية ، وبعد ذلك ستبدأ عملية معينة في الشعور بالبطء بالنسبة للمستخدم.

على سبيل المثال ، عند سحب العناصر على الشاشة ، يدرك المستخدمون تأخيرات تصل إلى 2 مللي ثانية فقط. يعتمد التأخير الأقل ملحوظة على المستخدم والإجراء الذي يتم تنفيذه ، ولكنه دائمًا ما يكون منخفضًا جدًا.

تصور السحب والإسقاط
تقرير التصور 2-16 مللي ثانية عند السحب باستخدام القلم .
2-11 مللي ثانية عند السحب بإصبع .
بمتوسط ​​11 مللي ثانية عند السحب بإصبع .

تم الحصول على نتائج مماثلة عند الرسم باستخدام القلم على الجهاز اللوحي. هنا ، اقترح الباحثون أن يلاحظ المستخدمون تأخيرًا يتراوح من 20 إلى 80 مللي ثانية. في اختباراتنا غير الرسمية الخاصة بنا ، يُنظر إلى التأخير الذي يبلغ 80 مللي ثانية تقريبًا على أنه أمر ملحوظ للغاية ، ويأخذ القلم أكثر من 20 مللي ثانية حتى يظهر القلم مستجيباً أثناء الكتابة اليدوية.

قلم تأخر الإدراك
تقرير عن إدراك التأخير 10−70 مللي ثانية عند الكتابة باستخدام القلم .
21-82 مللي ثانية لمختلف الإجراءات مع القلم .

الفرق بين الكمون المنخفض والكبير للكتابة اليدوية واضح عند مقارنة:

على اليسار: تطبيق iPad Pro و Notes مع وقت استجابة من طرف إلى طرف يبلغ حوالي 15 مللي ثانية. على اليمين: تطبيق Samsung S3 و OneNote مع تأخير حوالي 70 مللي ثانية. الفيديو أبطأ 16 مرة.

عملية نموذجية أخرى على الأجهزة التي تعمل باللمس هي النقر على الأزرار أو الروابط. هنا ، حددت الاختبارات أن المستخدمين يلاحظون تأخيرًا في حوالي 70 مللي ثانية (على الرغم من أنه ربما يكون أقل بالنسبة لبعض المستخدمين الفرديين).

تصور تأخير الشاشة
كشفت هذه الدراسة عن متوسط ​​أدنى تأخير يمكن تمييزه يبلغ 69 مللي ثانية.

فيما يلي مثال لمقارنة تأخيرين مختلفين:

على اليسار: فتح علامة تبويب الإعدادات على iPhone 6s مع تأخير حوالي 90 مللي ثانية. اليمين: تبديل الإعدادات على Samsung S3 مع تأخير حوالي 330 مللي ثانية. الفيديو أبطأ 16 مرة.

كيف تفي التطبيقات الحديثة بهذه العتبات؟ إذا تحدثنا عن السحب والإفلات ، فلن يكون هناك نظام تجاري قادر على التوافق مع التأخير لعدة مللي ثانية لإرضاء جميع المستهلكين.

سحب وإسقاط الأداء
كما سنرى أدناه ، حتى الشاشات والمعدات لإدخال البيانات لا تتناسب مع ميزانية 10 مللي ثانية ، ناهيك عن عدة طبقات من البرامج.

وبالتالي ، عند استخدام جميع أنظمة التشغيل الحالية مع شاشة تعمل باللمس ، سيشعر بعض المستخدمين على الأقل أن الكائن خلف إصبعك عند السحب والإسقاط.

عند الرسم باستخدام القلم ، يقترب عدد قليل من الأنظمة من مستوى تأخير منخفض بشكل مقبول. لكن معظمها أعلى بكثير من هذه القيم ، والتي يتوقعها المستخدمون كتأخير كبير:

فيما يلي نتائج اختبارات Ink & Switch على التأخير في الرسم باستخدام القلم على الجهاز اللوحي لمختلف الأجهزة. يتم تقريب متوسط ​​التأخيرات ، المقاسة من التلامس مع الشاشة إلى بداية تغيير لون البكسل المقابل ، إلى أقرب 5 مللي ثانية.

الجهاز	البرنامج	تأخير (مللي ثانية)
iPad Pro	ملاحظات	20
	ملاحظات جيدة	30
	رفرفة	35
جهاز Surface Pro	OneNote	25
	لوحة رسم	30
	قماش	60
Pixelbook	الحبار	40
	قماش	60
سامسونج s3	الحبار	60
	رفرفة	65
	قماش	75
	Liveboard	80

على الرغم من أننا لا نمتلك بيانات حول التأخيرات على جميع الأجهزة ، إلا أننا نفترض أنها قابلة للمقارنة بتأخيرات رسم القلم التي لوحظت أعلاه.

رسم التأخيرات مقابل تأخيرات النقر
نتوقع أن تكون هذه التأخيرات قابلة للمقارنة ، لأنه في كلتا الحالتين ، يتم استخدام الإدخال باللمس ، أي يتم تنشيط دورة تحديث الشاشة. ومع ذلك ، هناك بعض الاختلافات ، لذلك من غير المرجح أن تكون القيم هي نفسها تمامًا.

نظرًا لأن التأخير الذي يبلغ 70 مللي ثانية يمكن تمييزه هنا ، فإن معظم الأنظمة قادرة على الاستجابة بشكل جيد للنقرات. ولكن من السهل أيضًا العثور على التطبيقات التي تعمل بشكل أسوأ بكثير من القدرات النظرية للنظام.

بشكل عام ، يجب أن يكون للأنظمة الحسية وقت استجابة منخفض جدًا لجعلها تشعر بالاستجابة. معظم الأجهزة والتطبيقات غير قادرة على توفير هذا المستوى من الأداء ، وبالتالي فهي تشعر جميعها ، بدرجات متفاوتة ، بالبطء بالنسبة للمستخدمين.

لوحة المفاتيح

هناك بعض الأدلة على أن زيادة وقت الاستجابة للطباعة يضعف تجربة المستخدم.

تأثير تأخير الإدخال
في هذه الدراسة ، تمت إضافة تأخيرات عشوائية إلى ضغطات المفاتيح ، مما قلل من أداء الإدخال. ومع ذلك ، قام بتقييم نطاق واحد فقط من التأخير. بالإضافة إلى ذلك ، يقترح مؤلفو الدراسة أن الحروف المطبوعة يمكن أن تتكيف مع الكمون المتزايد.

ومع ذلك ، لسنا على علم بالدراسات التي تقيس على وجه التحديد أقل تأخيرات في الإدخال ملحوظة. يمكن أن يكون التأخير في الضغط على شاشة اللمس (يمكن ملاحظته عند حوالي 70 مللي ثانية) دليلاً مفيدًا لأنه يقيس أيضًا الوقت بين لمسة منفصلة من الإصبع والتحديث المرئي للشاشة.

فيما يلي بعض القياسات غير الرسمية لتأخير لوحة المفاتيح من البداية إلى النهاية من بداية ضغطة مفتاح إلى ظهور شخصية على أجهزة مختلفة. المصادر: "كمون الكمبيوتر: 1977-2017" ، اختبارات الحبر والتبديل.

كمبيوتر	تأخير (مللي ثانية)
التفاح iie	30
كومودور بيت 4016	60
iMac g4 OS 9	70
Macbook Pro 2014	100
هاسويل مخصص 24 هرتز	140
سامسونج s3	150
Powerspec g405 لينكس	170
الرموز 3620	300

ستكون القياسات الدقيقة لتأثيرات كمون لوحة المفاتيح تجربة رائعة للباحثين المغامرين. على أي حال ، يبدو من المرجح أن الحد الأدنى لتأخير ملموس عند الدخول من لوحة المفاتيح أقل من 100 مللي ثانية بالنسبة للعديد من المستخدمين. ربما أقل بكثير.

فأر

أحدث نوع من أجهزة الإدخال في مراجعتنا. حددت إحدى التجارب أن المستخدمين قد لاحظوا أن وقت استجابة الماوس يتراوح من 34 إلى 137 مللي ثانية بمتوسط ​​65 مللي ثانية.

الفئران المختلفة لها قيم تأخير مختلفة للغاية. تُظهر بعض الأنظمة قيمًا أقل من 10 مللي ثانية من خلال دمج المعدات عالية الأداء مع البرمجة الدقيقة ذات المستوى المنخفض (يصف هذا التثبيت بتأخير يبلغ حوالي 8 مللي ثانية). بالإضافة إلى ذلك ، يمكنك تجاوز 100 مللي ثانية على مجموعة من المعدات والتطبيقات المتوسطة التي تقدم تأخيرات إضافية ، أو مخازن بين الماوس والشاشة.

التطبيقات

تقيس التأخيرات على مستوى التطبيق المدة التي يستغرقها تنفيذ إجراءات تطبيق معينة ، مثل تحميل صفحات الويب. مثال على هذا التأخير هو تحميل صفحة NYTimes على الويب ، والتي تستغرق حوالي 3000 مللي ثانية.


متى تبدو إجراءات التطبيق سريعة؟ من الصعب القول بالتأكيد ، لأن أفعالهم أكثر تعقيدًا وتنوعًا من إدخال البيانات البسيطة. ربما تعتمد الإجابة أيضًا على توقعات المستخدمين (عادةً ما يعمل الأشخاص مع البرامج البطيئة). ولكن يمكننا حساب العدد التقريبي.

تأجيل الأدب
راجع مراجعة الأدبيات حول تأثير التأخير على مستخدمي التطبيقات المختلفة. هذه نقطة بداية جيدة لانغماس أعمق في الموضوع.

إحدى القيم المرجعية هي مقياس نموذجي يبلغ 70 مللي ثانية باعتباره أقل تأخير مرئي مذكور أعلاه عند النقر على الشاشة. إذا لاحظت تأخيرًا بين النقر على رابط وعرض مؤشر النقر ، فيجب أن تلاحظ تأخيرًا مشابهًا بين النقر على صفحة ويب وفتحها.

مرجع آخر هو نموذج مطور Google RAIL . على الرغم من أن مؤلفي هذا النموذج لا يدعمون بياناتهم بأي شكل من الأشكال ، إلا أن النموذج يدعي أن الاستجابة في غضون 100 مللي ثانية "تبدو فورية" وأن التأخير الأعلى "[يكسر] العلاقة بين الفعل ورد الفعل".

يمكنك التحقق من حساسيتك بشكل غير رسمي في المحطة. خذ برامج سطر الأوامر المفضلة لديك وقم بتشغيلها باستخدام معلمة "الوقت" ، والتي تقيس وقت التنفيذ. لاحظ بالتأكيد الفرق بين الردود لمدة 15 مللي ثانية (ممتاز!) و 500 مللي ثانية (بطيئة بشكل واضح).



كنقطة مرجعية أخيرة ، نأخذ في الاعتبار أن وقت رد الفعل البشري النموذجي للمنبه البصري حوالي 220 مللي ثانية .

هذه القيمة أكبر بكثير من تأخر ملحوظ ، لأن التفاعل لا يشمل فقط الملاحظة ، ولكن أيضًا الإجراء اللاحق.

من الضروري أيضًا أن نأخذ في الاعتبار استنتاجات بعض الباحثين بأن الشخص قادر على إدراك زيادة التأخير على المستوى الفسيولوجي اللاواعي.

تطبيقات حقيقية

كيف تتناسب التطبيقات الحقيقية مع هذه الإرشادات؟ البعض يتأقلم. على سبيل المثال ، تعمل العديد من برامج سطر أوامر Unix بشكل أسرع من 100 مللي ثانية.

لكن معظم تطبيقات الإنترنت خارج النطاق. يعد بحث Google في حوالي 1000 مللي ثانية أسرع بكثير من معظم تطبيقات الويب ، ولكنه لا يزال أبطأ بشكل ملحوظ مقارنة بأقل من 100 مللي ثانية في سطر الأوامر. ومن السهل العثور على أمثلة للصفحات التي يتم تحميلها لفترة أطول من 5000 مللي ثانية حتى عند الاتصال الجيد.

في حالة أجهزة الكمبيوتر المحمولة وأجهزة سطح المكتب ، هناك بعض التطبيقات التي تظهر باستمرار تأخيرًا أقل من 100 مللي ثانية ، مثل الآلة الحاسبة المدمجة على iOS. ولكن من السهل العثور على أمثلة للتطبيقات التي تتجاوز هذا الحد إلى حد كبير ، حتى إذا كان لديها جميع البيانات المتاحة (أو يجب أن تكون) محليًا. لنأخذ مثال سلاك.

يُظهر الفيديو أدناه أن التبديل بين قناتين منخفضتي الحجم في نفس مساحة العمل على iPad Pro يستغرق حوالي 220 مللي ثانية ، على الرغم من عدم الحاجة إلى مكالمات الشبكة ، ويمكن القول أن iPad Pro هو الجهاز المحمول الأفضل أداءً في العالم (يتم إبطاء الفيديو بمقدار 8 مرات ):


من الصعب استخلاص استنتاج عام لجميع البرامج في مجال واسع مثل تأخير العمل. ومع ذلك ، يبدو من الواضح أن بعض التطبيقات تؤدي إجراءات بسرعة كافية وتبدو فورية للمستخدمين (أقل من 100 مللي ثانية) ، لكن العديد من التطبيقات لا تفعل ذلك.

من أين يأتي التباطؤ؟

وهكذا ، وجدنا أن العديد من البرامج تعمل في الواقع ببطء. إلى أين يذهب كل هذا الوقت وما الذي يمكننا تحسينه؟ ضع في اعتبارك هذه المشكلة ، بدءًا من المكون الأول في السلسلة: أجهزة الإدخال.

جهاز الإدخال

الخطوة الأولى في خط الأنابيب ، والتي تحول بيانات المدخلات المادية إلى تحديثات على الشاشة ، هي معالجة بيانات الإدخال: تحويل جهة الاتصال مع شاشة اللمس أو لوحة المفاتيح أو الماوس إلى إشارة رقمية لنظام التشغيل. هنا نلقي نظرة على الوقت الذي تستغرقه هذه الخطوة.

لنبدأ مع لوحات المفاتيح. يوضح الجدول التأخيرات المقيسة من بداية ضغطة مفتاح إلى إشارة على لوحة وصل USB ، تقريبًا حتى 5 مللي ثانية ( المصدر ).

لوحة المفاتيح	تأخير (مللي ثانية)
سحر التفاح	15
داس 3	25
الحركة الحرة 2	30
إرجودوكس	40
ميزة Kinesis	50
لوجيتك MK360	60

كما ترون ، فإن لوحات المفاتيح هذه تأخذ بسهولة عشرات الملي ثانية من الميزانية في الخطوة الأولى في خط المعالجة. هذا من ميزانية إجمالية 100 مللي ثانية أو أقل! يتم تناول هذا الموضوع بمزيد من التفصيل في مقالة "الطباعة بسرور" .

وبالمثل ، تأخذ الفئران عشرات المللي ثانية من الميزانية. على الرغم من أن أكثر فئران الألعاب عالية الأداء لديها تأخير أقل من 10 مللي ثانية. تختلف البيانات المتعلقة بالاستجابة للضغط ، هنا أيضًا ، تظهر الحالات الفردية نتيجة أقل من 10 مللي ثانية ( مثال ).

في الأجهزة المحمولة ، من الأصعب قياس نسبة التأخير التي تقع على أجهزة الإدخال لأنها مدمجة بإحكام مع مكونات الأجهزة الأخرى. ومع ذلك ، يمكننا استخدام بعض الأنماط الشائعة في معدات أجهزة الإدخال لتقييم تأخيراتها ، بالإضافة إلى الأجهزة المستقلة.

معدل أخذ العينات

أحد النماذج الشائعة هو معدل أخذ العينات. في العديد من أجهزة الإدخال ، تقوم المعدات "بمسح" أو "عينات" الإدخال على فترات دورية. على سبيل المثال ، تعمل شاشة اللمس الاستهلاكية النموذجية بتردد 60 هرتز ، أي أنها تستقصي أجهزة الاستشعار تقريبًا كل 17 مللي ثانية. هذا يعني أنه في أسوأ الحالات ، سيكون تأخير جهاز الإدخال 17 مللي ثانية على الأقل ، وفي المتوسط ​​لا يزيد عن 8 مللي ثانية.

إذا كانت جميع الأشياء متساوية ، فإن معدل المسح العالي سيقلل من تأخير الإدخال. على سبيل المثال ، تعمل شاشات اللمس والأقلام المتقدمة من Apple بترددات أعلى من 60 هرتز (معلومات من أرشيف وثائق Apple ).

الجهاز	شاشة تعمل باللمس (هرتز)	قلم (هرتز)
آيفون 6	60
آيفون 7	60
آيفون 8	60
iPhone X	120
iPad Air 2	60
iPad Mini 4	60
iPad Pro	120	240

مصدر مماثل للتأخير هو اقتراع USB. يتلقى بروتوكول USB الإدخال من لوحة المفاتيح ، لذا تحتاج لوحة المفاتيح إلى انتظار استطلاع USB لإرسال معلومات حول النقرات. يعمل استطلاع USB بسرعة منخفضة عند 125 هرتز ، مما يؤدي إلى حدوث أمر حتمي ~ 8 مللي ثانية كحد أقصى. و ~ 4 مللي ثانية متوسط ​​التأخير. الإصدارات اللاحقة من مسح USB بتردد 1000 هرتز أو أكثر ، مما يقلل من تأثير التأخير.

هناك العديد من مصادر التأخير المحتملة الأخرى في أجهزة الإدخال ، على سبيل المثال ، ارتداد جهات الاتصال (لمزيد من التفاصيل ، راجع مقالة "مسح مصفوفة لوحة المفاتيح وارتداد جهات الاتصال" حول تأثيرات البرامج والارتداد).

لن نأخذ بعين الاعتبار كل هذه الفروق الدقيقة هنا ، ولكننا نؤكد على ما يلي: أ) أجهزة الإدخال نفسها يمكن أن تسبب تأخيرًا كبيرًا قبل حدوث أي معالجة في البرنامج ؛ ب) قد يكون هذا بسبب عدة أسباب منفصلة ، ويضاف وقت التأخير.

يعرض ووحدات معالجة الرسومات

الأجهزة في الطرف الآخر من الناقل هي شاشات العرض وبطاقات الفيديو.

أحد مصادر التأخير هنا هو معدل إطار العرض. نظرًا لأنه لا يمكن إعادة رسم شاشات العرض باستمرار ، فإن هذا يؤدي إلى تأخير لا مفر منه مشابه لأجهزة إدخال الاستقصاء الموضحة أعلاه. إذا تم تحديث الشاشة (قل) كل 20 مللي ثانية ، فإنها تضيف 20 مللي ثانية من التأخير في أسوأ الحالات و 10 مللي ثانية في المتوسط.

تصور الحركة
تؤثر عوامل أخرى على إدراكنا للأشياء التي تتحرك على الشاشة. Blur Busters هو مورد ممتاز حول هذا الموضوع. على سبيل المثال ، انظر القطع الأثرية حركة LCD 101 .

تعمل معظم الشاشات بتردد 60 هرتز ، على الرغم من أن الأجهزة المهنية وشاشات الألعاب تعمل بتردد 120 هرتز و 144 هرتز و 240 هرتز. وبالتالي ، عادة ما يضيف معدل إطارات العرض فقط إلى التأخير بمتوسط ​​8 مللي ثانية تقريبًا ، على الرغم من أنه في العروض ذات معدل الإطارات الأعلى يمكن تقليله إلى بضع مللي ثانية.

مساهمة أخرى في التأخير من الشاشات هي الوقت المستغرق لتغيير لون البكسل ماديًا بعد تلقي بيانات جديدة. تختلف هذه المرة من بضع مللي ثانية في شاشات الألعاب المتطورة إلى قيم مزدوجة الرقم في شاشات LCD الأقل استجابة.

عرض وقت الاستجابة
من الصعب قياس هذه المعلمة ، ولكن تتوفر بعض البيانات التوضيحية على موقع Notebook Check على الويب . على سبيل المثال، انظر مثال من بطء و سرعة العرض.

على الأجهزة الحديثة المتطورة ، يتم توصيل الشاشة بمعالج رسومات خاص (GPU). تنشئ وحدات معالجة الرسومات مجموعة من وحدات البكسل للعرض ، على سبيل المثال ، من خلال ترتيب طبقات ثنائية الأبعاد أو عرض مشاهد افتراضية ثلاثية الأبعاد. تنتج GPUs إطارات بسرعة تعتمد على أجهزة GPU ، والتفاعل مع التطبيق ورمز النظام الأساسي ، وأحيانًا على منطق المزامنة مع الشاشات.

تحدث مشكلة ذات صلة عندما يكون رمز التطبيق بطيئًا للغاية ولا يرسل تعليمات إلى GPU بسرعة كافية لاستخدامه بالكامل. يمكن أن يؤدي هذا إلى إنشاء GPU لإطارات فريدة بسرعة أقل مما لو كان يحتوي بالفعل على تعليمات متكررة من التطبيق. هذا مصدر شائع للتأخر الذي نراه في التطبيقات ثنائية الأبعاد التي تعرض أقل من 60 إطارًا في الثانية.

قاي
قاي نوع 'الأحداث الغريبة "من الصعب وصف في الكلمات، ولكنها يمكن التعرف عليه بسهولة. يعرّف ناثان جيتر في مقالة Designing Jank-Free Apps أنها "أعطال بصرية غير متوقعة أو مشتتة للانتباه".

تراكب حلقة

ناقشنا ثلاثة أجزاء على الأقل من خط الأنابيب حيث يوجد تأخير بسبب النشاط المتقطع: المسح الضوئي للإدخال ، ودورات عرض GPU ، وعرض دورات التحديث. من المهم أن نلاحظ أنه يمكن دمجها بطريقة تضيف كل التأخيرات بشكل أساسي:


الانتظار لعدة دورات. يُظهر تسلسل التأخير الافتراضي كيف يمكن أن يؤدي انتظار دورات الأجهزة المتتالية إلى تراكم التأخير. تشير الخطوط الرأسية المتقطعة إلى الدورات التي يجب أن يتوقعها الناقل.

للانتقال إلى الخطوة التالية في خط الأنابيب ، يجب أن ننتظر حتى الدورة التالية. وقد لا يتم محاذاة الحلقات مع بعضها البعض. يمكن أن تتسبب الدورات غير المتسقة ووقت الإدخال الأولي غير المواتي في تأخير إضافي يبلغ 10 مللي ثانية. هذا مبلغ كبير مقارنة بميزانيات التأخير الموصوفة أعلاه.

وقت التشغيل العلوي

من ناحية البرامج ، فإن تأخيرات وقت التشغيل متأصلة في أنظمة التشغيل والتعليمات البرمجية الأخرى التي لا تتعلق مباشرة بالتطبيق. تأمل في مثالين مهمين: جمع القمامة والجدولة.

تأتي أولاً مجموعة القمامة (GC). يعتبر GC أمرًا حاسمًا في أكثر المنصتين استخدامًا في العالم: الويب (JavaScript) و Android (Java).

في بعض الحالات ، يمكن أن يؤدي تجميع البيانات المهملة إلى تأخير كبير ، خاصة فيما يتعلق بمتطلبات تأخر الإدخال المنخفض. بالنسبة لبيئات JavaScript أو Java ، فإن تأخيرات مجموعة البيانات المهملة التي تبلغ حوالي 10 مللي ثانية ليست مفاجئة. ولكن هذه هي كل ميزانية سحب الأشياء على شاشة اللمس!

جمع القمامة يمكن أن يؤخر إطار واحد فقط. ولكن كما في حالة التأخير بسبب فقدان الإطار ، فإن هؤلاء الهزات يزعجون المستخدمين.

هناك طرق لتقليل تأخير GC. وتشمل هذه نقل أكبر قدر ممكن من عمل GC خارج الخيط الرئيسي ، وتحسين GC لبضع فترات توقف منفصلة فقط. انظر ، على سبيل المثال ، جهود V8 لنقل أكبر عدد ممكن من عمليات جمع القمامة خارج التيار الرئيسي وجهود Go لزيادة الحد الأقصى لتأخر GC أقل بكثير من 1 مللي ثانية.

هناك خيار آخر لاستخدام لغة برمجة تضحي جزئيًا براحة GC ، ولكن لديها أداء يمكن التنبؤ به بشكل أكبر. تتجنب لغات مثل Swift جمع القمامة التعسفي باستخدامالعد المرجعي التلقائي .

مصدر آخر محتمل للنفقات العامة هو التخلص من نظام التشغيل. تطبيقنا (وتبعياته في نظام التشغيل) لا يعمل بالضرورة باستمرار. يمكن جدولة إطلاق برامج أخرى ، بينما يتم تعليق برامجنا بالقوة ، وإن كان ذلك لفترة قصيرة جدًا. يستغرق كل برنامج وقتًا ، كما أن عدد نوى المعالج محدود.

تتعلق مشكلة الإرسال باستخدام وحدة المعالجة المركزية. إذا كان تطبيقك يحقق أهداف الأداء الخاصة به ، ولكنه يتطلب ما يقرب من 100٪ من موارد الحوسبة ، فقد يزعج ذلك المستخدمين. سيزداد استهلاك البطارية ، وسوف يسخن الجهاز وقد يبدأ في إحداث ضوضاء بمروحة. بمعنى آخر ، ceteris paribus ، الاستخدام المنخفض لوحدة المعالجة المركزية هو الأفضل للمستخدم.

تأخير متعمد

يعد تصميم نظام التشغيل نفسه والتطبيقات أحد المصادر النموذجية للتأخير في واجهات الهاتف المحمول. هناك بعض التفاعلات المهمة التي لا يمكن تحقيقها إلا بتوقع حقيقي.

يستخدم Android و iOS بشكل كبير "الضغط لفترة طويلة" للوصول إلى قائمة السياق. إنها تتطلب من المستخدم الانتظار مئات الملي ثانية لتنفيذ الأمر.

هناك تأخيرات مرتبطة بهذا للقضاء على الغموض. على سبيل المثال ، في Safari للجوال ، هناك تأخير افتراضي قدره 350 مللي ثانية بين نقر المستخدم على الرابط ووقت بدء المتصفح في تحميل صفحة جديدة. يعد ذلك ضروريًا لتحديد الفرق بين النقر فوق ارتباط والنقر المزدوج (تكبير / تصغير). لمعرفة هذا التأخير المحدد ، انظر هنا لمزيد من التفاصيل.. هناك أيضًا معلومات حول أحدث التغييرات التي تسمح لمطوري التطبيقات بالتغلب على هذه المشكلة.

وكلاء معادية

يعد النشاط الضار أحد المصادر الشائعة للتأخير للمستخدمين على الإنترنت ، على سبيل المثال ، متتبعات النشاط التي تتتبع إجراءات المستخدم وتنزيل الإعلانات المتطفلة.


تتطلب مقالة من 500 كلمة على موقع واشنطن بوست حوالي مائة طلب HTTP وتستغرق حوالي 4400 مللي ثانية للتحميل. هناك حاجة إلى العديد من الاستفسارات للمتتبعين والإعلانات. يتم عرض جزء صغير منها ،

وهناك العديد من المقالات الرائعة حول السمنة على الويب: انظر The Bullshit Web و "The Crisis of Obesity Sites" و Web bloat وغيرها. نؤكد

ببساطة أن أكبر مصدر للتأخير في العديد من المواقع هو تنزيل جميع أنواع الهراء ضد رغبات المستخدمين.

كود التطبيق

ربما يكون المصدر الأخير للتأخير الذي نذكره هو الأكثر وضوحًا: هذا هو التطبيق نفسه. إذا كان التطبيق يقضي الكثير من وقت معالجة المعالج لإدخال أو تنفيذ إجراء ، فسيكون بطيئًا.

ضع كل ذلك معًا

ضع في اعتبارك مثال ما يتكون منه التأخير الكلي:


مثال افتراضي للتأخير من طرف إلى طرف من الإدخال إلى العرض على الشاشة. تشير الخطوط العمودية المتقطعة إلى الدورات التي يجب أن يتوقعها الناقل ،

والمثال أعلاه افتراضي ، ولكنه إرشادي. يوضح عدد الطبقات التي تضيف تأخيرًا ، لذلك يمكن أن يكون التطبيق بطيئًا جدًا ، حتى لو تم تشغيله بمعدل إطارات كامل.

لبرمجيات سريعة

إن رزمة التكنولوجيا العميقة مسؤولة عن الاستجابة لواجهة الكمبيوتر الحديثة بإجراءات المستخدم. حتى الضغط على مفتاح بسيط على لوحة المفاتيح وظهور الحرف المطابق في مربع نص الإدخال هي عملية تمر عبر سلسلة معقدة طويلة من الخطوات: من مسح لوحة المفاتيح ، من خلال طبقات معالجة نظام التشغيل والإطار ، من خلال عرض بطاقة الفيديو ومعدل تحديث الشاشة.

هناك سبب لمثل هذا التعقيد ، ومع ذلك نشعر بالحزن لأن مستخدمي الكمبيوتر الذين يحاولون العمل بشكل منتج غالبًا ما يظلون ينتظرون ، ويشاهدون رمز الساعة الرملية ويشعرون أن أجهزتهم ببساطة لا تستطيع مواكبة ذلك.

نحن نؤمن بأن البرنامج السريع يمكّن المستخدمين ويجعلهم أكثر إنتاجية. نحن نعلم أن برنامج اليوم غالبًا ما يفشل المستخدمين ، كونه بطيئًا ، ونريد تحسين الوضع. نأمل أن تكون هذه المواد مفيدة لك عند العمل على برنامجك الخاص.

الأدب

1. إندو ، وانغ ، تشين ، سيلتزر. "تأخير كفاءة النظام التفاعلي" ، وقائع ندوة USENIX الثانية حول تصميم أنظمة التشغيل وتنفيذها ، 1996.

2. Ng، Annette، Ditz، Gupta، Bischoff. "في أي وقت من الأوقات دراسة: تأخير تصور التفاعل مع القلم» ، وقائع المؤتمر السنوي للACM 32 على العوامل البشرية في أنظمة الحاسبات ، 2014.

3. نغ Lepinsk، Vigdor، ساندرز، ديتز. "تطوير الأجهزة مع الإدخال باللمس المباشر مع الكمون المنخفض" ، وقائع الندوة السنوية الخامسة والعشرين لـ ACM حول برامج وتكنولوجيا واجهة المستخدم ، 2012.

4. Deber، Jota، Forlays، Wigdor."ما هي السرعة الكافية؟ تصور المستخدم للتأخير وتحسينه في واجهات اللمس المباشرة وغير المباشرة " ، وقائع المؤتمر السنوي الثالث والثلاثين ACM حول العوامل البشرية في أنظمة الحوسبة ، 2015.

5. Annette، Ng، Ditz، Bischof، Gupta. "إلى أي مستوى يجب أن يذهب المرء؟ فهم إدراك التأخير في الرسم " ، وقائع واجهة الرسوميات 2014 ، 2014.

6. Forch ، Franke ، Rauch ، Krems. "هل 100 مللي ثانية كافية؟" توصيف عتبة التأخير في التفاعل مع الفأرة " ، علم النفس الهندسي وبيئة العمل المعرفية: الإدراك والتصميم ، 2017.

7. دابروفسكي ، مانسون.«40 » , Interacting with Computers , 2011.

8. -, , , , . « » , 38th International ACM SIGIR Conference on Research and Development in Information Retrieval , 2015.