পারফরম্যান্স — অনুমান নয়, মেপে দ্রুত করা

১ · অনুমান নয়, মাপুন — আর “যথেষ্ট দ্রুত” আগে ঠিক করুন

মিরপুরের একটি সুপারশপের হিসাব রাখেন সুমাইয়া। প্রতি রাতে একটি Python স্ক্রিপ্ট দিনের সব বিক্রি (প্রায় দুই লাখ লাইন) পড়ে, প্রতিটি বিক্রির পণ্যের দাম খুঁজে বের করে, আর একটি রিপোর্ট বানায়। শুরুতে দোকানে পণ্য ছিল কয়েকশো, স্ক্রিপ্ট শেষ হতো চোখের পলকে। এখন পণ্য বিশ হাজার, আর স্ক্রিপ্ট চলে প্রায় এক মিনিট। মালিক বলছেন, “আরও শাখা খুলছি, তখন কী হবে?”

সুমাইয়ার প্রথম ভাবনা: “CSV পড়াটাই নিশ্চয়ই ধীর, ফাইলটা তো বিশাল।” তিনি ইন্টারনেট ঘেঁটে CSV পড়ার তিনটি “দ্রুত” পদ্ধতি চেষ্টা করলেন, দুই দিন গেল — স্ক্রিপ্ট দুই সেকেন্ডও দ্রুত হলো না। কারণ সময় আসলে CSV পড়ায় যাচ্ছিলই না। যাচ্ছিল এমন একটি লাইনে, যা দেখতে একদম নিরীহ। এই পর্বের শেষে আপনি সেই লাইনটি নিজেই খুঁজে বের করবেন — আন্দাজে নয়, মেপে।

এই গল্পের শিক্ষাটি পারফরম্যান্সের প্রথম নিয়ম: প্রোগ্রাম কোথায় সময় নষ্ট করছে, তা অভিজ্ঞ প্রোগ্রামারও আন্দাজে প্রায়ই ভুল বলেন. আধুনিক কম্পিউটার, Python-এর interpreter, অপারেটিং সিস্টেমের file cache — এত স্তর আছে যে “এটাই নিশ্চয়ই ধীর” অনুভূতি প্রায়ই মেলে না। তাই পদ্ধতিটি হলো একটি চক্র: মাপুন → profile করুন → hotspot খুঁজুন → শুধু সেটি ঠিক করুন → আবার মাপুন.

Knuth-এর বিখ্যাত কথা — পুরোটা পড়ুন

“Premature optimization is the root of all evil” — কথাটি প্রায়ই শোনা যায়, প্রায়ই ভুলভাবে। বলেছিলেন কম্পিউটার বিজ্ঞানী Donald Knuth, ১৯৭৪ সালে। পুরো বাক্যটি এরকম: ছোটখাটো দক্ষতার কথা প্রায় ৯৭% সময় ভুলে যাওয়া উচিত — অসময়ের optimization সব অনিষ্টের মূল; তবু বাকি গুরুত্বপূর্ণ ৩%-এর সুযোগ হাতছাড়া করা উচিত নয়. অর্থাৎ Knuth বলেননি “গতি নিয়ে ভাববেন না”. বলেছেন: যে অংশ আসলে গুরুত্বপূর্ণ নয়, সেখানে কোড জটিল করে লাভ নেই; আর কোন অংশ গুরুত্বপূর্ণ, সেটি মেপে জানুন। (প্রসঙ্গসহ পুরো গল্প ভাবনার প্রশ্ন ১-এ।)

“যথেষ্ট দ্রুত” — কাজভেদে আলাদা

Optimize শুরুর আগে একটি সংখ্যা ঠিক করুন — নইলে কখন থামবেন জানবেন না। “যত দ্রুত সম্ভব” কোনো লক্ষ্য নয়। কয়েকটি উদাহরণ:

• রাতের রিপোর্ট: সকালের আগে শেষ হলেই যথেষ্ট। ৫ মিনিট লাগুক বা ৫ সেকেন্ড, কারও কিছু যায় আসে না — যতক্ষণ না ডেটা বেড়ে ঘণ্টায় পৌঁছায়।
• ওয়েবসাইটের একটি পেজ: ব্যবহারকারী ক্লিক করে অপেক্ষা করছেন। কয়েকশো মিলিসেকেন্ডের বেশি লাগলে দেরি চোখে পড়ে, কয়েক সেকেন্ড লাগলে অনেকে চলে যান।
• একবার চালানোর স্ক্রিপ্ট: একটি পুরোনো ফাইল একবার রূপান্তর করবেন — ১০ মিনিট লাগলে চা খেয়ে আসুন। দুই ঘণ্টা optimize করে ৯ মিনিট বাঁচানো লোকসান।
• লাখো ব্যবহারকারীর সার্ভার: এখানে প্রতি অনুরোধে কয়েক মিলিসেকেন্ড বাঁচানো মানে কম সার্ভার, কম বিদ্যুৎ, কম খরচ — তাই এখানে গভীর optimization-এর মূল্য আছে।

সুমাইয়ার ক্ষেত্রে লক্ষ্য স্পষ্ট: “দশটি শাখার ডেটা হলেও রিপোর্ট ২ সেকেন্ডের মধ্যে, আর রিপোর্টের প্রতিটি সংখ্যা আগের মতোই।” শেষ অংশটি ভুলবেন না — দ্রুত কিন্তু ভুল প্রোগ্রাম কোনো উন্নতি নয়. তাই optimize করার আগে পর্ব ৩৯-এর মতো কিছু unit test থাকা চাই, যা প্রতিটি বদলের পরে প্রমাণ করবে ফলাফল একই আছে। এবার পুরো চক্রটি ধাপে ধাপে দেখুন:

$ python report.py
রিপোর্ট তৈরি: 200000 বিক্রি, 20000 পণ্য
মোট সময়: 41.9 s        # লক্ষ্য: 2 s-এর কম

$ python -m cProfile -s cumtime report.py
   ncalls  tottime  cumtime  function
        1    0.310   41.870  build_report
   200000    0.402   41.214  find_product
   200000   40.812   40.812  {method 'index' of 'list'}

def find_product(code):
    i = codes.index(code)   # list-এ রৈখিক খোঁজ
    return products[i]      # প্রতি বিক্রিতে গড়ে
                            # ১০,০০০ তুলনা!

by_code = {p["code"]: p for p in products}  # একবার

def find_product(code):
    return by_code[code]   # গড়ে O(1)

$ pytest -q
6 passed                   # ফলাফল আগের মতোই
$ python report.py
মোট সময়: 0.6 s            # লক্ষ্য পূরণ — এখানেই থামুন

২ · সময় মাপা — perf_counter, timeit আর মাপের “গোলমাল”

পুরো কাজ মাপা: time.perf_counter()

একটি বড় কাজ (পুরো রিপোর্ট, একটি ফাংশনের একটি ডাক) কতক্ষণ নেয়, তা মাপার সহজ উপায় পর্ব ২৭-এ দেখা time.perf_counter(). এটি একটি উচ্চ-নির্ভুল ঘড়ি; এর মানের নিজস্ব কোনো অর্থ নেই, শুধু দুটি মানের পার্থক্যই সময়। time.time() ব্যবহার করবেন না — সেটি দেয়ালঘড়ির সময়, যা কম্পিউটারের ঘড়ি ঠিক করলে (যেমন ইন্টারনেট থেকে সময় মিলিয়ে নিলে) লাফ দিতে পারে।

import time

start = time.perf_counter()
report = build_report(sales, products)     # যে কাজটি মাপতে চান
elapsed = time.perf_counter() - start
print(f"মোট সময়: {elapsed:.2f} s")

এটি মাপে wall-clock time — শুরু থেকে শেষ পর্যন্ত আসল যে সময় গেল, তার মধ্যে ডিস্ক বা নেটওয়ার্কের অপেক্ষাও আছে। শুধু CPU কতক্ষণ কাজ করল, জানতে চাইলে time.process_time() আছে; অপেক্ষার সময় সেখানে গোনা হয় না। দুটির বড় পার্থক্য নিজেই একটি সূত্র: wall-clock অনেক বেশি হলে প্রোগ্রাম কাজ করছে না, অপেক্ষা করছে (অংশ ৭)।

ছোট টুকরো মাপা: timeit

এক লাইনের কোড, যা এক মাইক্রোসেকেন্ডে চলে — তাকে perf_counter দিয়ে একবার মাপলে ঘড়ির নিজের খরচই মাপের চেয়ে বড় হয়ে যায়। এর জন্য স্ট্যান্ডার্ড লাইব্রেরির timeit module: সে কোডটি হাজার হাজার বার চালায়, মোট সময়কে ভাগ করে, আর পুরো পরীক্ষাটি কয়েকবার করে। টার্মিনাল থেকে সবচেয়ে সহজ:

python -m timeit "sum(range(1000))"
python -m timeit -s "nums = list(range(1000))" "999 in nums"
python -m timeit -s "nums = set(range(1000))" "999 in nums"

-s-এর পরের অংশ (setup) একবারই চলে, মাপা হয় না; শেষের অংশটি বারবার চলে আর মাপা হয়। আউটপুট দেখতে এরকম:

# উদাহরণ — আপনার মেশিনে সংখ্যা আলাদা হবে
50000 loops, best of 5: 6.1 usec per loop
50000 loops, best of 5: 5.4 usec per loop
5000000 loops, best of 5: 42.3 nsec per loop

পড়ুন এভাবে: “কোডটি একটানা ৫০,০০০ বার চালানো হলো, এমন পাঁচটি দফা হলো, সবচেয়ে ভালো দফায় প্রতিবারে গড়ে ৬.১ মাইক্রোসেকেন্ড।” কতবার চালাবে, timeit নিজেই ঠিক করে, যাতে একেকটি দফা যথেষ্ট লম্বা হয় (কমপক্ষে ০.২ সেকেন্ড)। শেষ দুই লাইনের তুলনা লক্ষ করুন: হাজার উপাদানের list-এ শেষ উপাদান খুঁজতে কয়েক মাইক্রোসেকেন্ড, set-এ কয়েক দশ ন্যানোসেকেন্ড — একশো গুণেরও বেশি পার্থক্য (কারণ অংশ ৪-এ)।

কোডের ভেতর থেকেও চালানো যায়। timeit.timeit-এ number= বলে দেয় কতবার চালাতে হবে (না দিলে ১০ লাখ বার!), আর ফল আসে মোট সেকেন্ডে:

import timeit

nums_list = list(range(10_000))
nums_set = set(nums_list)
t_list = timeit.timeit(lambda: 9_999 in nums_list, number=1_000)
t_set = timeit.timeit(lambda: 9_999 in nums_set, number=1_000)
print(f"list: {t_list:.4f} s, set: {t_set:.6f} s  (১,০০০ বার)")

Jupyter বা IPython-এ আরও সহজ: লাইনের আগে %timeit লিখলেই চলে।

মাপ কেন প্রতিবার আলাদা — আর কী করবেন

একই কোড দুবার মাপুন — দুটি আলাদা সংখ্যা পাবেন। এটা ভুল নয়, এটা বাস্তবতা। আপনার প্রোগ্রাম একা চলে না:

• অন্য প্রোগ্রাম: browser, antivirus, আপডেট — সবাই একই CPU ভাগ করে নিচ্ছে।
• CPU-র গতি বদলায়: ল্যাপটপ চার্জে আছে না ব্যাটারিতে, গরম হয়ে গেছে কি না — CPU নিজের গতি বাড়ায়-কমায়।
• প্রথমবার ধীর: প্রথম দফায় ফাইল ডিস্ক থেকে আসে, পরে মেমরির cache থেকে; module import-ও প্রথমবারে।
• Garbage collector: হঠাৎ কোনো এক দফায় garbage collection চলে সময় বাড়িয়ে দিতে পারে। (timeit মাপার সময় এটি default-এ বন্ধ রাখে।)

৩ · Profiler — সময় আসলে কোথায় যায়

timeit বলে কতক্ষণ, কিন্তু বলে না কোথায়. পাঁচশো লাইনের একটি প্রোগ্রামে প্রতিটি ফাংশনের চারপাশে হাতে perf_counter বসানো অসম্ভব। এই কাজের টুল হলো profiler: প্রোগ্রাম চলার সময় সে নজর রাখে কোন ফাংশন কতবার ডাকা হলো আর প্রতিটিতে কত সময় গেল। Python-এর সাথেই আসে cProfile (C-তে লেখা, তাই নিজে কম ধীর করে)। কোড না বদলেই চালানো যায়:

python -m cProfile -s cumtime report.py
python -m cProfile -o report.prof report.py     # ফলাফল ফাইলে রাখা

-s cumtime মানে টেবিলটি “মোট সময়” অনুযায়ী সাজানো হবে। সুমাইয়ার রিপোর্টে আউটপুটের ওপরের অংশ দেখতে এরকম (ছোট করে দেখানো):

# উদাহরণ — আপনার মেশিনে সংখ্যা আলাদা হবে
         600214 function calls in 42.118 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000   42.118   42.118 {built-in method builtins.exec}
        1    0.009    0.009   42.118   42.118 report.py:1(<module>)
        1    0.310    0.310   41.870   41.870 report.py:21(build_report)
   200000    0.402    0.000   41.214    0.000 report.py:9(find_product)
   200000   40.812    0.000   40.812    0.000 {method 'index' of 'list' objects}
        1    0.161    0.161    0.239    0.239 report.py:13(read_sales)
   200000    0.078    0.000    0.078    0.000 {method 'split' of 'str' objects}

কলামগুলোর মানে:

tottime আর cumtime-এর পার্থক্যই টেবিল পড়ার চাবি। একটি অফিসের কথা ভাবুন: ম্যানেজারের “cumtime” হলো তাঁর বিভাগের পুরো কাজের সময়, কিন্তু তাঁর “tottime” হলো শুধু তিনি নিজে যতক্ষণ কাজ করলেন — বাকিটা তিনি অন্যদের দিয়ে করিয়েছেন। Hotspot হলো সেই কর্মী, যার নিজের সময় (tottime) বড়। এবার টেবিলটি সারি ধরে পড়ুন:

600214 function calls in 42.118 seconds
ncalls  tottime  cumtime  function
     1    0.000   42.118  builtins.exec
     1    0.009   42.118  <module>
     1    0.310   41.870  build_report
200000    0.402   41.214  find_product
200000   40.812   40.812  list.index
     1    0.161    0.239  read_sales

600214 function calls in 42.118 seconds
ncalls  tottime  cumtime  function
     1    0.000   42.118  builtins.exec
     1    0.009   42.118  <module>
     1    0.310   41.870  build_report
200000    0.402   41.214  find_product
200000   40.812   40.812  list.index
     1    0.161    0.239  read_sales

600214 function calls in 42.118 seconds
ncalls  tottime  cumtime  function
     1    0.000   42.118  builtins.exec
     1    0.009   42.118  <module>
     1    0.310   41.870  build_report
200000    0.402   41.214  find_product
200000   40.812   40.812  list.index
     1    0.161    0.239  read_sales

600214 function calls in 42.118 seconds
ncalls  tottime  cumtime  function
     1    0.000   42.118  builtins.exec
     1    0.009   42.118  <module>
     1    0.310   41.870  build_report
200000    0.402   41.214  find_product
200000   40.812   40.812  list.index
     1    0.161    0.239  read_sales

600214 function calls in 42.118 seconds
ncalls  tottime  cumtime  function
     1    0.000   42.118  builtins.exec
     1    0.009   42.118  <module>
     1    0.310   41.870  build_report
200000    0.402   41.214  find_product
200000   40.812   40.812  list.index
     1    0.161    0.239  read_sales

আরও কিছু টুল — কখন কোনটি

tracemalloc বিশেষ কাজে লাগে যখন সমস্যা সময় নয়, মেমরি — যেমন ৫ GB-র একটি লগ ফাইল পুরোটা একবারে list-এ পড়তে গিয়ে প্রোগ্রাম MemoryError দিচ্ছে বা কম্পিউটার জমে যাচ্ছে। এর সমাধানও প্রায়ই algorithm-গোছের: সব একসাথে না রেখে একটি একটি করে প্রক্রিয়া করা (অংশ ৬-এর generator).

৪ · আগে algorithm — সবচেয়ে বড় লাভ এখানেই

সুমাইয়ার hotspot-এ codes.index(code) কী করে? সে list-এর প্রথম উপাদান থেকে শুরু করে একটি একটি করে মেলায়, যতক্ষণ না পায় — পর্ব ১৪-এর linear search. বিশ হাজার উপাদানের list-এ গড়ে দশ হাজার তুলনা। list-এ x in items-ও ঠিক একই কাজ করে। এর খরচ list-এর দৈর্ঘ্যের সমানুপাতিক — Big-O ভাষায় O(n).

অন্যদিকে পর্ব ১৬-১৭-এর set আর dict ভেতরে একটি hash table: চাবির hash থেকে সরাসরি হিসাব করে কোন ঘরে দেখতে হবে। তাই খোঁজ গড়ে O(1) — set-এ দশটি থাকুক বা দশ লাখ, খোঁজার খরচ প্রায় একই। (“গড়ে” কথাটি গুরুত্বপূর্ণ; অনেক চাবির hash একই ঘরে পড়লে খারাপ ক্ষেত্রে ধীর হতে পারে, কিন্তু বাস্তবে প্রায় কখনো ঘটে না।)

লুপের ভেতরে O(n) — লুকানো O(n²)

একটি list-খোঁজ নিজে ধীর নয় — হাজার উপাদানে কয়েক মাইক্রোসেকেন্ড। বিপদ হয় যখন সেটি একটি লুপের ভেতরে বসে। n বার ঘোরা লুপের প্রতিটি ধাপে n উপাদানের খোঁজ মানে মোট প্রায় n × n কাজ — O(n²). পর্ব ১২-এর nested loop সরাসরি লেখা না থাকলেও এটি একটি nested loop; in বা .index()-এর ভেতরে লুকিয়ে আছে। n বাড়লে কী ঘটে, গুনে দেখুন:

1# ক: প্রতিটি বিক্রিতে পুরো list-এ খোঁজ2for sale in sales:                 # n বার3    p = products[codes.index(sale.code)]  # n পর্যন্ত45# খ: একবার dict বানানো, তারপর সরাসরি6by_code = {p.code: p for p in products}  # n7for sale in sales:                 # n বার8    p = by_code[sale.code]         # গড়ে ১

প্রমাণ গুনে দেখা: এক লাখ কন্টাক্টে ডুপ্লিকেট ফোন নম্বর

একটি বাস্তব কাজ: একটি কোম্পানির এক লাখ গ্রাহকের ফোন নম্বর আছে, কোনগুলো একাধিকবার এসেছে বের করতে হবে। সরল পদ্ধতি — প্রতিটি নম্বরকে তার পরের প্রতিটি নম্বরের সাথে মেলানো। ভালো পদ্ধতি — একটি set-এ “দেখা হয়েছে” নম্বর রাখা। নিচের প্রোগ্রামটি সময় মাপে না (সময় মেশিনভেদে বদলায়); বরং গোনে কতগুলো ধাপ লাগল — যা যেকোনো মেশিনে একই:

def dup_nested(phones):
    dups, steps = set(), 0
    for i in range(len(phones)):
        for j in range(i + 1, len(phones)):
            steps += 1                    # একটি তুলনা
            if phones[i] == phones[j]:
                dups.add(phones[i])
    return dups, steps

def dup_set(phones):
    seen, dups = set(), set()
    for p in phones:                      # প্রতিটি নম্বরে একটি set-খোঁজ
        if p in seen:
            dups.add(p)
        seen.add(p)
    return dups, len(phones)

for n in (10, 100, 1000):
    phones = [f"017{i % (n - 2):08d}" for i in range(n)]   # শেষ ২টি ডুপ্লিকেট
    (d1, s1), (d2, s2) = dup_nested(phones), dup_set(phones)
    print(f"n={n:>4}: nested {s1:>6} তুলনা | set {s2:>4} ধাপ | মিল {d1 == d2}, ডুপ্লিকেট {len(d2)}")
print(f"n=100000 হলে nested: {100_000 * 99_999 // 2:,} তুলনা")

আরও কয়েকটি algorithm-গোছের ভুল

• বারবার sort করা: প্রতিটি নতুন বিক্রি যোগ করার পর পুরো list sorted() করা — n বার O(n log n). সব যোগ করে একবার sort করুন। সবসময় সাজানো রাখতেই হলে bisect.insort, আর শুধু সবচেয়ে বড় ১০টি দরকার হলে heapq.nlargest(10, items) — পুরোটা sort করার দরকারই নেই।
• লুপের ভেতরে একই হিসাব: for row in rows: if row.total > average(rows): ... — প্রতিটি সারির জন্য পুরো list-এর গড় আবার হিসাব, আবার O(n²). গড় লুপের আগে একবার হিসাব করে রাখুন।
• list-এর সামনে থেকে সরানো: queue.pop(0) প্রতিবার বাকি সব উপাদান এক ঘর সরায় — O(n). সারি (queue) দরকার হলে পর্ব ২৭-এর collections.deque, যার popleft() O(1).
• ভুল প্রশ্ন: কখনো সবচেয়ে বড় লাভ আসে কাজটিই না করে — দশ লাখ সারি Python-এ এনে ফিল্টার করার বদলে ডেটাবেসকে WHERE দিয়ে শুধু দরকারি ১০০ সারি দিতে বলা।

৫ · Python-এর নিজস্ব কৌশল — লুপটা C-তে ঠেলে দিন

Algorithm ঠিক থাকার পরেও Python-এ একটি বিশেষ সত্য কাজে লাগে। পর্ব ০৫-এ দেখেছেন, আপনার Python কোড bytecode-এ রূপান্তরিত হয়, আর CPython-এর virtual machine সেই নির্দেশগুলো একটি একটি করে চালায়। প্রতিটি নির্দেশে বাড়তি খরচ: type যাচাই, object তৈরি, reference গোনা। অন্যদিকে built-in function-গুলো (sum, max, min, sorted, any, all, len, str.join…) C-তে লেখা — তাদের ভেতরের লুপ machine code হিসেবে সরাসরি CPU-তে চলে। তাই নিয়মটি: যে লুপ একটি built-in বা লাইব্রেরি করে দিতে পারে, তা নিজে Python-এ লিখবেন না.

total = 0
for x in nums:          FOR_ITER       → পরের উপাদান
                        STORE_FAST     → x-এ রাখা
    total += x          LOAD_FAST ×2   → total, x আনা
                        BINARY_OP (+=) → যোগ
                        STORE_FAST     → total-এ রাখা
                        JUMP_BACKWARD  → আবার ওপরে

BINARY_OP (+=):
  x কোন type? int — ঠিক আছে
  total কোন type? int — ঠিক আছে
  যোগফলের জন্য নতুন int object
  পুরোনো total-এর reference কমানো
# ১০ লাখ সংখ্যা = এই সব ১০ লাখ বার

total = sum(nums)       CALL → C ফাংশন builtin_sum
                        # ভেতরের লুপ C-তে:
                        # bytecode dispatch নেই,
                        # ছোট int যোগ হয় C-র সংখ্যায়

import numpy as np
arr = np.arange(1_000_000)   # একটানা int64-এর সারি
total = arr.sum()            # সংকলিত C লুপ,
                             # CPU একসাথে কয়েকটি যোগ করে

এই ভাবনার নাম vectorization — “প্রতিটি উপাদানে এটা করো” লুপ না লিখে পুরো সারির ওপর একটি কাজ বলে দেওয়া, যাতে আসল লুপটি দ্রুত, সংকলিত কোডে চলে। NumPy, pandas, PyTorch — Python-এর পুরো ডেটা আর AI জগৎ এই নীতির ওপর দাঁড়িয়ে।

প্রতিদিনের Python-এ এর প্রয়োগ

বড় CSV লাইন: join বনাম +=

পর্ব ০৯-এ দেখেছেন, Python-এর string immutable — বদলানো যায় না। তাই line += field + "," নীতিগতভাবে প্রতিবার একটি নতুন string বানায় আর আগের সব অক্ষর কপি করে: ১০,০০০টি ঘর জুড়লে মোট কপি প্রায় n²÷২। CPython বিশেষ ক্ষেত্রে (string-টির আর কোনো reference না থাকলে) জায়গায় বাড়িয়ে নেওয়ার একটি কৌশল করে, তাই অনেক সময় এটা ততটা ধীর দেখায় না — কিন্তু এর ওপর ভরসা করা যায় না: অন্য implementation-এ (যেমন PyPy) বা সামান্য ভিন্ন কোডে কৌশলটি কাজ করে না। PEP 8 নিজেই বলে, এ কাজে join ব্যবহার করুন:

# ধীর হতে পারে: প্রতিবার নতুন string, পুরোনো অক্ষর কপি
line = ""
for value in row:
    line += str(value) + ","

# সঠিক উপায়: টুকরোগুলো জমিয়ে একবারে জোড়া
line = ",".join(str(value) for value in row)

(বাস্তবে CSV লিখতে পর্ব ২৬-এর csv module-ই ব্যবহার করুন — কমা বা উদ্ধৃতিচিহ্নওয়ালা ঘরও সে ঠিকভাবে সামলায়। এখানে মূল কথা হলো অনেক টুকরো থেকে একটি বড় string বানানোর concatenation-এর ধরন।)

৬ · বারবার কাজ এড়ানো আর মেমরি বাঁচানো

একই হিসাব দ্বিতীয়বার নয় — functools.lru_cache

একটি অনলাইন দোকান বিদেশি মুদ্রায় অর্ডার নেয়, আর প্রতিটি অর্ডারের দাম টাকায় রূপান্তর করে। রূপান্তর হার আনার ফাংশনটি ধীর — হয়তো একটি API ডাকে বা জটিল হিসাব করে। ছয় হাজার অর্ডার, কিন্তু মুদ্রা মাত্র তিনটি! প্রতিটি অর্ডারে হার নতুন করে আনা মানে ৫,৯৯৭টি অকারণ ধীর কাজ। পর্ব ৩৫-এর functools.lru_cache ঠিক এই সমস্যার সমাধান: প্রথমবার হিসাব করে উত্তর খাতায় রাখে, পরে একই প্রশ্নে খাতা থেকে বলে দেয় — memoization. আবারও সময় নয়, গুনে দেখুন:

from functools import lru_cache

slow_calls = 0

@lru_cache(maxsize=None)
def rate(src, dst):
    global slow_calls
    slow_calls += 1                     # ধরুন এখানে ধীর হিসাব বা API ডাক
    table = {("USD", "BDT"): 122.0, ("EUR", "BDT"): 132.5,
             ("INR", "BDT"): 1.45}
    return table[(src, dst)]

orders = [("USD", 10), ("EUR", 5), ("USD", 3),
          ("INR", 200), ("USD", 7), ("EUR", 2)] * 1000
total = sum(amount * rate(cur, "BDT") for cur, amount in orders)

print(f"অর্ডার {len(orders)}টি, মোট {total:,.2f} টাকা")
print("ধীর হিসাব চলেছে:", slow_calls, "বার")
print(rate.cache_info())

লুপের ভেতর থেকে অপরিবর্তিত কাজ বের করুন

লুপের প্রতিটি পাকে যে কাজের ফল বদলায় না, তা লুপের বাইরে একবার করুন: একটি regex compile করা (re.compile, পর্ব ২৮), একটি ফাইল খোলা, একটি কনফিগ পড়া, একটি বড় list থেকে set বানানো, len(items) বা গড় হিসাব। শুনতে স্পষ্ট, কিন্তু profiler-এর টেবিলে সবচেয়ে বেশি দেখা যাওয়া সমস্যার একটি এটি — বিশেষত যখন অপরিবর্তিত কাজটি অন্য একটি ফাংশনের ভেতরে লুকানো থাকে, যা লুপ থেকে ডাকা হয়।

ছোট কৌশল: local নাম বনাম global নাম

একটি local variable পড়া (LOAD_FAST) একটি global বা built-in নাম খোঁজার চেয়ে কিছুটা সস্তা। তাই পুরোনো লেখায় দেখবেন খুব গরম লুপের আগে append = result.append বা sqrt = math.sqrt লিখে নাম local করে নেওয়ার কৌশল। এটি সত্যি, কিন্তু একটি micro-optimization: লাভ সাধারণত কয়েক শতাংশ, আর Python 3.11-এর পরে global খোঁজাও cache হওয়ায় লাভ আরও কমেছে। কোড পড়তে অস্বাভাবিক লাগে। শুধু তখনই ভাবুন, যখন profiler বলছে ঠিক এই লুপটিই hotspot, আর algorithm আর built-in-এর পথ শেষ। একই কথা “comprehension বনাম append লুপ” নিয়েও — comprehension সাধারণত একটু দ্রুত আর বেশি পরিষ্কার, তাই পরিষ্কারতার জন্যই ব্যবহার করুন; গতির লাভটা বোনাস।

মেমরি: generator আর __slots__

পর্ব ৩৪-এর generator সব উপাদান একসাথে মেমরিতে রাখে না, একটি একটি করে তৈরি করে। sum([x * x for x in range(10_000_000)]) আগে এক কোটি সংখ্যার একটি পুরো list বানায় (কয়েকশো MB), তারপর যোগ করে; sum(x * x for x in range(10_000_000)) একবারে একটি সংখ্যাই রাখে। ৫ GB-র লগ ফাইলও for line in f: দিয়ে লাইন ধরে পড়লে মেমরি প্রায় স্থির থাকে। মেমরি কম লাগলে প্রায়ই সময়ও কম লাগে — বড় list বানানো আর মোছারও খরচ আছে।

পর্ব ২৯-এ দেখেছেন, সাধারণ object-এর প্রতিটির নিজস্ব একটি __dict__ থাকে — attribute রাখার একটি ছোট dict. দশ লাখ ছোট object (যেমন প্রতিটি বিক্রির একটি Sale object) হলে দশ লাখ dict! Class-এ __slots__ ঘোষণা করলে (__slots__ = ("code", "qty", "price")) object-গুলো dict ছাড়া নির্দিষ্ট ঘরে attribute রাখে — প্রতিটি object উল্লেখযোগ্যভাবে ছোট হয়, attribute পড়াও সামান্য দ্রুত। দাম: নতুন attribute চলার সময় যোগ করা যায় না। Python 3.10 থেকে @dataclass(slots=True) লিখলেই হয়। কয়েকশো object-এ এর কোনো দরকার নেই; লাখো object-এ tracemalloc দিয়ে মেপে তারপর সিদ্ধান্ত নিন।

৭ · দ্রুততর runtime, C/Rust, আর I/O-র অপেক্ষা

Algorithm ঠিক, built-in ব্যবহার করা হয়েছে, তবু একটি বিশুদ্ধ-Python হিসাব লক্ষ্যের চেয়ে ধীর? তখন আসে বড় অস্ত্রগুলো। সহজ থেকে কঠিন ক্রমে:

শেষ পথটি নতুন কিছু নয় — Python-এর জনপ্রিয় লাইব্রেরিগুলোর বড় অংশ ঠিক এভাবেই তৈরি। NumPy-র ভেতর C, পুরোনো গাণিতিক অংশে Fortran-এর ঐতিহ্য; Pydantic 2-এর মূল অংশ (pydantic-core) Rust-এ PyO3 দিয়ে লেখা; Polars নামের ডেটা লাইব্রেরিও Rust-এ। আপনি import করে Python-এর আরাম পান, কাজটা হয় সংকলিত কোডে। তবে মনে রাখুন: নিজের প্রজেক্টে এই পথ নেওয়া মানে দুটি ভাষা, একটি build পদ্ধতি আর বেশি রক্ষণাবেক্ষণ। প্রায় সব ক্ষেত্রে অংশ ৪-৫-এর কাজ এবং একটি তৈরি লাইব্রেরিই যথেষ্ট।

প্রোগ্রাম কাজ করছে, নাকি অপেক্ষা করছে?

একটি স্ক্রিপ্ট ৫০০টি ওয়েবসাইট থেকে দাম আনে, ১০ মিনিট লাগে। Profiler দেখায় সময়ের প্রায় সবটা যাচ্ছে নেটওয়ার্ক থেকে উত্তরের অপেক্ষায়। এই কাজ I/O-bound — CPU প্রায় অলস বসে থাকে। এখানে PyPy, Cython বা algorithm কিছুই সাহায্য করবে না, কারণ সমস্যা হিসাব নয়, অপেক্ষা। সমাধান হলো অপেক্ষাগুলো একসাথে করা: পর্ব ৪১-এর thread বা পর্ব ৪২-এর asyncio দিয়ে একসাথে ৫০টি অনুরোধ পাঠানো। ১০ মিনিট নেমে আসতে পারে কয়েক সেকেন্ডে।

উল্টো দিকে, যে কাজে CPU সত্যিই ব্যস্ত (ছবি প্রক্রিয়া, বড় হিসাব) — CPU-bound — সেখানে সাধারণ CPython-এ thread দিয়ে লাভ হয় না, কারণ GIL একসাথে একটি thread-কেই Python bytecode চালাতে দেয়। সেখানে multiprocessing, NumPy-র মতো লাইব্রেরি (যারা ভারী কাজের সময় GIL ছেড়ে দেয়), বা free-threaded build (পর্ব ৪১)। মূল প্রশ্নটি তাই প্রথমেই: wall-clock সময় বনাম CPU সময় — অংশ ২-এর দুটি ঘড়ির পার্থক্য এখানেই কাজে লাগে।

৮ · কখন optimize করবেন না

পারফরম্যান্সের সবচেয়ে গুরুত্বপূর্ণ দক্ষতা হলো জানা কখন কিছুই না করা উচিত:

• কোড এখনো ঠিকমতো কাজ করে না: আগে সঠিক, তারপর পরিষ্কার, তারপর — দরকার হলে — দ্রুত। ভুল উত্তর দ্রুত দেওয়া কোনো অর্জন নয়।
• লক্ষ্য ইতিমধ্যে পূরণ: রিপোর্ট ০.৬ সেকেন্ডে হয়, লক্ষ্য ছিল ২ সেকেন্ড। ০.৩-এ নামাতে একদিন খরচ করা লোকসান।
• মাপা হয়নি: “এটা নিশ্চয়ই ধীর” অনুভূতির ভিত্তিতে বদল নয়। আগে সংখ্যা।
• লাভ ছোট, দাম বড়: ৩% গতির জন্য কোড অর্ধেক পড়া যায় না এমন করা — পরের মানুষটি (ছয় মাস পরের আপনি) এর দাম দেবেন, বাগ খুঁজতে গিয়ে।
• এক্ষেত্রে সময় অন্য কোথাও: পেজ খুলতে ২ সেকেন্ড, যার ১.৮ সেকেন্ড ডেটাবেস কোয়েরিতে — Python লুপ ঘষেমেজে লাভ নেই; কোয়েরি বা index ঠিক করুন।

৯ · AI-এর যুগে — না-মাপা “দ্রুত” দাবি যাচাই করা

“এই কোডটা optimize করে দাও” — AI খুশিমনে নতুন কোড দেয়, সঙ্গে আত্মবিশ্বাসী দাবি: “এটি এখন ৩ গুণ দ্রুত।” কিন্তু AI আপনার কোড আপনার ডেটায় চালায়নি, মাপেনি। সংখ্যাটি প্রায়ই অনুমান — কখনো সত্যের কাছাকাছি, কখনো একদম উল্টো। পারফরম্যান্সে AI-এর লেখায় বারবার যে ভুলগুলো দেখা যায়:

AI-এর “optimize করা” কোড পেলে — যাচাইয়ের চেকলিস্ট

• বদলের আগে নিজের মেশিনে, বাস্তবের মতো ডেটায় সময় মেপে রেখেছি
• প্রস্তাবিত বদলটি profiler-এর hotspot-এ পড়েছে, অন্য কোথাও নয়
• পুরোনো আর নতুন কোডের ফল একই — test চালিয়ে দেখেছি
• বদলের পরে নিজে আবার মেপেছি; AI-এর দাবি করা সংখ্যা নয়, আমার মাপা সংখ্যা রেখেছি
• কাজটি I/O-bound না CPU-bound যাচাই করেছি (wall-clock বনাম CPU সময়) — concurrency-র প্রস্তাব সেই অনুযায়ী
• কোড এখনো পড়ে বোঝা যায়; লাভ ছোট হলে পাঠযোগ্য পুরোনো রূপটিই রেখেছি