کیا ہم خالص آپٹیمائزیشن کا فن کھو چکے ہیں؟
ابتدائی دور کے انجینئرز بہت محدود وسائل کے ساتھ کام کرتے تھے۔ Apollo Guidance Computer میں صرف 2KB RAM تھی۔ ہر ایک بٹ (bit) اہمیت رکھتا تھا۔ CPU کا ہر سائیکل (cycle) انتہائی اہم تھا۔
آج ہمارے پاس گیگا بائٹس (gigabytes) کی میموری ہے۔ ہم اکثر مزید ہارڈ ویئر شامل کر کے مسائل حل کر لیتے ہیں۔ اگر کوڈ سست یا بھاری ہو، تو ہم مزید RAM شامل کر دیتے ہیں۔ یہ عادت ہمیں خالص آپٹیمائزیشن کی مہارت سے دور کر دیتی ہے۔
آپ حدود (constraints) کے بارے میں سوچ کر بہتر سافٹ ویئر لکھ سکتے ہیں۔
دیکھیں کہ آپ Python میں ایک بڑی ٹیکسٹ فائل کو کیسے پروسیس کرتے ہیں۔
عام طریقہ: بہت سے ڈویلپرز ایک ہی بار میں پوری فائل کو میموری میں لوڈ کر لیتے ہیں۔
- آپ
f.readlines()استعمال کرتے ہیں۔ - یہ آپ کی RAM میں ایک لسٹ کے طور پر ہر لائن کو لوڈ کر دیتا ہے۔
- اگر آپ کی فائل 10GB کی ہے، تو آپ کو 10GB RAM کی ضرورت ہوگی۔
- یہ طریقہ چھوٹے سرورز یا محدود ڈیوائسز پر ناکام ہو جاتا ہے۔
بہتر (Optimized) طریقہ: فائل کو ایک وقت میں ایک لائن کے حساب سے پروسیس کریں۔
- آپ براہ راست فائل آبجیکٹ (file object) پر اٹریشن (iterate) کرتے ہیں۔
- Python ایک لائن پڑھتا ہے، اسے پروسیس کرتا ہے، اور پھر اگلی لائن پر چلا جاتا ہے۔
- آپ کے میموری کا استعمال کم اور مستقل رہتا ہے۔
- اس سے کوئی فرق نہیں پڑتا کہ فائل 1MB کی ہے یا 100GB کی۔
یہ فرق انجینئرنگ کے فلسفے کا ہے۔
مزید وسائل کا اضافہ کرنا ایک عارضی حل ہے۔ یہ کمزور سافٹ ویئر تخلیق کرتا ہے۔ اپنے ڈیزائن کو بہتر بنانے کے لیے حدود (constraints) کا استعمال کرنا ایک مضبوط (robust) سافٹ ویئر تخلیق کرتا ہے۔
آپٹیمائزیشن کا مطلب صرف رفتار نہیں ہے۔ اس کا مطلب اپنے وسائل کے بارے میں باخبر رہنا ہے۔
جب آپ کوڈ لکھیں، تو خود سے پوچھیں:
- یہ کتنی میموری استعمال کرتا ہے؟
- کیا یہ تب بھی کام کرے گا اگر ڈیٹا دس گنا بڑھ جائے؟
- کیا میں برے کوڈ کو چھپانے کے لیے مہنگے ہارڈ ویئر پر انحصار کر رہا ہوں؟
بہتر سافٹ ویئر نظم و ضبط سے آتا ہے۔
ماخذ: https://dev.to/prabashanadev/have-we-lost-the-art-of-pure-optimization-31b9