سايمون ويليسون وClaude يسرّعان تحليل الأرقام في SQLite من 67 إلى 19 نانوثانية

صدّرتَ المدفوعات إلى ملف CSV وحمّلتها في SQLite، فإذا بعمود المبالغ يحتوي «-$1,234.56». بالنسبة للإنسان هذا رقم، أما بالنسبة لقاعدة البيانات فهو سلسلة نصية يجب تحليلها قبل الجمع والفرز. أراد سايمون ويليسون أن يختبر مدى صعوبة إضافة دالة parse_number() لهذا الغرض، وكلّف Claude بمقارنة تنفيذين بلغتي C وRust.

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

دالة SQL واحدة بدل التنظيف في كل استعلام

مهمة parse_number() بسيطة: إزالة الفواصل ورموز العملات وعلامة النسبة المئوية من السلسلة، ومراعاة علامة الناقص في البداية، وإرجاع القيمة العددية. وإذا تعذّر تحليل السلسلة، ترجع الدالة NULL. يتيح هذا السلوك نقل التنظيف المتكرر إلى إضافة SQLite ثم استخدام النتيجة في الحسابات.

مثلًا، يتحول «-$1,234.56» بعد حذف الدولار وفاصل الآلاف إلى -1234.56. وبعدها يمكن جمع هذه القيمة مع مدفوعات أخرى أو فرزها كرقم. ولا يضطر المطوّر إلى إعادة بناء سلسلة من الاستبدالات النصية في كل استعلام.

أما النسب المئوية فتستحق تحديد قواعدها على حدة. ففي طلبه الأول اقترح ويليسون حذف علامة النسبة المئوية. لكن في منتج بعينه يجب تحديد ما إذا كانت «12.5%» تعني الرقم 12.5 أم الكسر 0.125. وتتوقف صحة الحسابات اللاحقة على ذلك. والتحليل السريع للسلسلة بحد ذاته لا يتخذ هذا القرار نيابةً عن الفريق.

لماذا بدت Rust أسرع في البداية

أعدّ Claude نسخًا من الإضافة بلغة C ومع مكتبتين بلغة Rust: ‏rusqlite وsqlite-loadable-rs. ووفق ويليسون، بلغ حجم الإضافة المجمّعة بلغة C ‏14 كيلوبايت. أما نسختا Rust فبلغتا 321 و298 كيلوبايت على الترتيب. وبالنسبة لأداة مدمجة صغيرة قد يكون لهذا الفارق أهمية.

غير أن النسخة الأولى بلغة C كانت أبطأ. فعلى البيانات المختلطة بلغت تكلفة المعالجة الإضافية فيها 67 نانوثانية للسطر، بينما سجّلت نسختا Rust ‏46 و41 نانوثانية. وأرجع ويليسون الفارق إلى تحليل الأرقام: فالآلية المستخدمة في Rust كانت أسرع من الدالة القياسية strtod في C.

كان الطلب التالي إلى Claude محددًا: كتابة دالة خاصة بلغة C لتحليل الأعداد العشرية، قادرة على اللحاق بـRust أو تجاوزها. وبعد هذا الاستبدال سجّلت نسخة C زمن 19 نانوثانية على البيانات المختلطة، و16 نانوثانية على الأعداد الصحيحة، و18 نانوثانية على الكسور العشرية.

وللمقارنة: على الكسور العشرية احتاجت النسخة الأصلية بلغة C إلى 106 نانوثانية، بينما احتاجت نسختا Rust إلى 55 و47 نانوثانية. وجميع القياسات المذكورة تعود إلى تجربة على مليوني سطر. والحديث هنا عن تكلفة المعالجة الإضافية للسطر، لذا لا يجوز نقل هذه الأرقام مباشرة إلى زمن تنفيذ استعلام SQL كامل.

ما الذي يجب التحقق منه قبل الاستخدام

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

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

كما طلب ويليسون من Claude صياغة البحث ونشر النتيجة في مستودع simonw/research. وهي للمطوّر نقطة انطلاق: أعد القياسات على بياناتك المصدَّرة، وتحقق من الصحة، ثم اختر التنفيذ. وقد ساعد Claude في هذه القصة على قطع الطريق بسرعة من الفكرة إلى عدة نسخ مقيسة؛ ومع ذلك يبقى تقييم ملاءمتها مرهونًا بمتطلبات النظام المعني.