مثل الآخرين، لقد سلكت هذا المسار:
- ابدأ بقائمة، ربما تم تنزيلها من مستودع GitHub حالي.
- الوصول فورًا إلى حد 2000 إدخال.
- أوه، يمكنني استخدام التعبيرات العادية (Regex) - رائع!
- التعبيرات العادية المعقدة تتجاوز بسهولة 100 حرف.
- قسمها.
- قم بتحسين تعبير عادي، يا إلهي لقد امتد لأكثر من 100 حرف أيضًا.
- قسمها أكثر.
الرقص مع الحدود ليس مانعًا، إنه مزعج فقط، خاصة عندما تكون الحدود مصطنعة. ومع ذلك، أتفهم أن هذا الترشيح متزامن وأن المعالجة الممتدة يمكن أن تسبب مشاكل في الأداء، وأنا أقدر صعوبة محاولة وضع حدود تعمل لأكبر عدد ممكن من الجمهور. لذلك، بينما أكافح مع الحدود، لا يمكنني الاعتراض عليها بشكل معقول.
أرى الكود الخاص بالترشيح هنا في word_watcher.rb. بصفتي مطورًا، سأكون سعيدًا بتجربة كتابة إضافة (plugin)، لكن هذا الكود لا يبدو قابلاً للتوسيع. ليس لدي أي فكرة عن كيفية ربط JavaScript في إضافة لتعزيز عمليات Ruby … أو ما إذا كان ذلك ممكنًا مع كيفية كتابة كود word_watcher.
إليك فكرة لتحسين للمساعدة في تخفيف بعض عبء معالجة القوائم الموسعة.
بدلاً من معالجة القائمة بأكملها لكل نوع من قوائم المراقبة، فكر في حلقة عبر كتل مختلفة من المرشحات. على سبيل المثال، يمكننا وضع المرشحات الأكثر شيوعًا وإساءة استخدامًا في الكتلة 1 والمرشحات الأخرى في الكتل 2-ن. ستقوم عملية الترشيح المتزامنة بمعالجة كتلة واحدة فقط في كل مرة، ولن تقوم بحلقة كاملة عبر جميع المرشحات إلا عند عملية الحفظ النهائية. يمكن للكتل العمل على القوائم الموجودة، لذلك لا حاجة لأي شخص لإجراء تغيير. سيتم تقسيم القوائم الحالية إلى كتل من 1000 إدخال، لذا الكتلة 1 هي 1-1000، والكتلة 2 هي 1001-2000، وهكذا. يمكن للمسؤولين الذين يرغبون في التحسين الآن اختيار نقل مرشحاتهم ذات الأولوية الأعلى إلى أعلى القائمة.
إحدى مزايا هذا هي أنه لا يلزم معالجة القائمة بأكملها لاكتشاف مشكلة. سيتم اكتشاف المشكلات الأكثر احتمالاً باستخدام كتلة أصغر، ويمكن لعملية المعالجة المتزامنة أن تعود في وقت أقرب من معالجة الكتلة الأصغر. بالتأكيد، إذا لم يتم العثور على النص المراد مراقبته في الكتلة الأولى، فستحتاج كتلة أخرى إلى المعالجة. هذا يصبح مسألة عبء إضافي طفيف لالتقاط إساءة استخدام أقل احتمالاً. يصبح هذا مسألة ضبط اختياري - إذا أراد أي شخص الاهتمام بذلك.
خيار إضافي هنا سيكون للمسؤول اختيار حجم الكتل. عن طريق تقليل حجم الكتل، ربما إلى 500 إدخال لكل دورة، ستكون كل عملية متزامنة أسرع، ولكن قد يكون هناك المزيد من الكتل للمعالجة. هذا يعتمد على نوع الإساءة الموجودة ومدى جودة ترتيب القائمة. مرة أخرى، سيكون هذا النوع من الضبط اختياريًا، وبصراحة أشك في أن العديد من المسؤولين سيقومون بالكثير من الضبط مثل هذا.
لاحظ أن الضبط الدقيق يعني أن لدينا مقاييس قابلة للقياس: كم من الوقت نقضيه في معالجة الكلمات المراد مراقبتها وكم عدد المشكلات التي نلتقطها بالفعل؟ يجب ترك هذه التفاصيل التقنية لكمية كبيرة لوقت لاحق أو إضافة إذا كانت مرغوبة حقًا.
في النهاية، إذا تم تنفيذ “معالجة كتل الكلمات المراد مراقبتها” كما هو موضح هنا، فيمكن زيادة عدد العناصر في القائمة إلى ما بعد 2000. نعم، سيكون هناك بعض العبء الإضافي في قراءة قوائم أطول وتقسيمها. مرة أخرى، إذا كانت لدينا مقاييس حول مقدار الوقت المستهلك في هذه العملية، فيمكن للمسؤولين تحديد عتبتهم الخاصة للتحسين … لكنني أشك في أن الكثير من الناس سيتعمقون في هذا. يمكن أن يكون الدليل المنشور شيئًا مثل “يظل الحد 2000 كلمة مراقبة بدون معالجة كتل الكلمات المراد مراقبتها. مع معالجة الكتل، لا يوجد حد محدد، ولكن قد يُقدر الحد العملي بحوالي 5000، مع تدهور ملحوظ في الأداء يزداد مع زيادة عدد الإدخالات.”
هل هناك أي فائدة هنا؟