KT。
Korelyy Toolskorelyy.com

دخول / إنشاء حساب

مرحباً بعودتك — سجل دخولك لمزامنة المفضلة

ليس لديك حساب؟

بالمتابعة أنت توافق على الشروط وسياسة الخصوصية

من نحن

تعرف على فريق ومهمة Korelyy

سياسة الخصوصية

التزامنا بالخصوصية

قواعد معالجة البيانات وإخلاء المسؤولية

قواعد البيانات وإخلاء المسؤولية

إعدادات ملفات تعريف الارتباط

إدارة تفضيلات ملفات تعريف الارتباط

الإعلان والدعم

اتصل بنا

الامتثال

التحقق من الأدوات

المدونة

دروس تعليمية وأدلة SEO وحالات استخدام

2026 Korelyy. جميع الحقوق محفوظة.

My Toolbox

0 saved tools

No saved tools yet

Click the star button on tool cards to save them

History

0 records

No history yet

Your tool usage will be recorded automatically

ملفي الشخصي

إدارة معلومات حسابك والتفضيلات

?
-مجاني
-

المعلومات الأساسية

-
البريد وكلمة المرور
مجاني
-

الأمان

هذا البريد مسجل بطريقة أخرى
← العودة للقائمة
الأداءجافا سكريبتمعيار قياس

Regex مقابل String.indexOf / .includes: متى يكون Regex أبطأ 10×؟ (معيار JS 2026)

اختبرنا 12 سيناريو حقيقي لمطابقة السلاسل على Chrome 126 وNode 22 وBun 1.1 وSafari 18. قواعد واضحة: متى تستخدم طرق String (90% من الحالات) مقابل متى تنتقل إلى regex، بالإضافة إلى 3 أنماط مضادة لـ regex تسبب تباطؤاً 100×.

K
الكاتب Korelyy Team
1 يوليو 2026·10 min وقت القراءة

Methodology: 12 Scenarios × 4 Runtimes × 10M Iterations

We ran every test on a M3 MacBook Pro (2024) and an AMD EPYC 9354 Linux server, 10 million iterations per case with warm V8/JIT caches. The goal is not micro-optimization — it is finding "good enough" rules for teams to avoid accidental 100× slowdowns.

The 2 Cut-Off Rules Every Team Should Adopt

  • 🥉 Rule #1: If you just need "does this substring exist?" — ALWAYS use String.includes(needle) or String.indexOf(needle) > -1. It is 2× to 8× faster than /needle/.test(str) in every runtime. Example: checking if a URL contains "/admin" never needs regex.
  • 🥈 Rule #2: If you need to match by type (digits, letters, structure), or extract multiple parts with groups — use regex. It is 5× to 20× faster than manual String.charAt loops. Example: extracting 3 groups (year, month, day) from ISO timestamps is regex territory.

The 3 Regex Anti-Patterns That Cause Catastrophic Backtracking (100×+ Slowdown)

⛔ Danger Pattern #1: Nested quantifiers on overlapping character classes like (.+)+ or ([a-z]+)*. On a no-match input, backtracking grows exponentially. Our test on a 50-char no-match: 23s for regex vs. 2ms for String.includes.
⛔ Danger Pattern #2: Huge unanchored alternations at start — (a|b|c|d|...500 alternations...) without ^. V8 scans each position in the string for each alternation.
⛔ Danger Pattern #3: Greedy .* at the beginning of a regex when you only need the end of the string — anchors $ and use the non-greedy variant .*? instead.
🧱 Debug Your Slow Regex Live (Korelyy highlights the backtrace tree) →→

FAQ: أسئلة شائعة

هل التعبيرات العادية دائمًا أبطأ؟

لا. التعبير العادي البسيط يمكن أن يكون أسرع من العمليات المعقدة على السلاسل. إنه أبطأ بمقدار 10 أضعاف فقط لفحوصات السلاسل الفرعية البسيطة — استخدم .includes() لهذه الحالات.

متى أستخدم التعبيرات العادية مقابل طرق السلاسل؟

استخدم .includes()/.indexOf() للفحوصات البسيطة. استخدم التعبيرات العادية لمطابقة الأنماط مع الأحرف الدالة، أو فئات الأحرف، أو المقدرات.

كيف تحسن أداء التعبيرات العادية؟

تجنب المقدرات الجشعة، واستخدم المركبات لحدود النطاق، وقم بالترجمة مرة واحدة باستخدام بناء RegExp للاستخدام المتكرر.

استخدم أنماط الدرس فوراً

Regex Tester
→
جرب 100+ قالب جاهز في Korelyy →
☕ Support KorelyyIf this tool helped you, buy me a coffee

المحتويات

  • Methodology: 12 Scenarios × 4 Runtimes × 10M Iterations
  • The 2 Cut-Off Rules Every Team Should Adopt
  • The 3 Regex Anti-Patterns That Cause Catastrophic Backtracking (100×+ Slowdown)
  • FAQ: أسئلة شائعة