স্টাডাউটে মুদ্রণ কেন এত ধীর? তাড়াতাড়ি করা যায়?


166

মুদ্রণ বিবৃতি সহ টার্মিনালে আউটপুট নিতে কত সময় লাগে তা নিয়ে আমি সর্বদা অবাক / হতাশ হয়ে পড়েছি। সাম্প্রতিক কিছু বেদনাদায়ক ধীর লগিংয়ের পরে আমি এটি খতিয়ে দেখার সিদ্ধান্ত নিয়েছি এবং বেশ অবাক হয়েছি যে প্রায় সমস্ত সময় ব্যয় করে ফলাফলটি প্রক্রিয়া করার জন্য টার্মিনালের জন্য অপেক্ষা করছে।

Stdout লেখার কি কোনওভাবে গতি বাড়ানো যেতে পারে?

আমি print_timer.pyস্ট্রিডাউটে 100k লাইন লেখার সময় টাইমিংয়ের সাথে তুলনা করতে, ফাইলটি লেখার জন্য এবং stdout এ পুনঃনির্দেশিত দিয়ে একটি স্ক্রিপ্ট লিখেছিলাম (' ' এই প্রশ্নের নীচে) /dev/null। সময় ফলাফল এখানে:

$ python print_timer.py
this is a test
this is a test
<snipped 99997 lines>
this is a test
-----
timing summary (100k lines each)
-----
print                         :11.950 s
write to file (+ fsync)       : 0.122 s
print with stdout = /dev/null : 0.050 s

কি দারুন. পাইথন পর্দার আড়ালে কিছু করছে না তা নিশ্চিত করার জন্য যে আমি স্ট্যাডআউটকে / ডিভ / নাল বা অন্য কিছুতে পুনর্নির্দিষ্ট করেছি, আমি স্ক্রিপ্টের বাইরে পুনর্নির্দেশটি করেছি ...

$ python print_timer.py > /dev/null
-----
timing summary (100k lines each)
-----
print                         : 0.053 s
write to file (+fsync)        : 0.108 s
print with stdout = /dev/null : 0.045 s

সুতরাং এটি একটি অজগর কৌশল নয়, এটি কেবল টার্মিনাল। আমি সর্বদা ডেম্পিং আউটপুট / ডিভ / নাল স্পিডের জিনিসগুলিতে জানতাম, তবে কখনই টের পাইনি যে তা উল্লেখযোগ্য!

টিটিটি কত ধীর গতিতে তা আমাকে অবাক করে দেয়। এটি কীভাবে হতে পারে যে শারীরিক ডিস্কে লেখা "স্ক্রিনে" লেখার চেয়ে সম্ভবত দ্রুত (সম্ভবত একটি অল-র‍্যাম বিকল্প), এবং কার্যকরভাবে / দেব / নাল দিয়ে আবর্জনায় ফেলে দেওয়ার মতো কার্যকর?

এই লিঙ্কটি কীভাবে টার্মিনালটি I / O- কে অবরুদ্ধ করবে সে সম্পর্কে আলোচনা করে যাতে এটি "ইনপুট] পার্স করতে পারে , এর ফ্রেম বাফারটি আপডেট করতে পারে, উইন্ডোটি স্ক্রোল করার জন্য এক্স সার্ভারের সাথে যোগাযোগ করতে পারে ইত্যাদি" ... তবে আমি করি না সম্পূর্ণরূপে এটি পেতে। এতক্ষণ কী লাগতে পারে?

আমি আশা করি এর বাইরে কোনও উপায় নেই (দ্রুত tty বাস্তবায়নের সংক্ষিপ্ত?) তবে চিত্রটি আমি যেভাবেই জিজ্ঞাসা করব।


আপডেট: কিছু মন্তব্য পড়ার পরে আমি ভাবলাম যে আমার স্ক্রিনের আকারটি মুদ্রণের সময়ে আসলে কতটা প্রভাব ফেলেছে এবং এর কিছুটা তাত্পর্য রয়েছে। উপরের সত্যই ধীর সংখ্যাগুলি আমার জিনোম টার্মিনালটির সাথে 1920x1200 অবধি ফুটিয়েছে। আমি যদি এটি খুব কম করি তবে আমি পাই ...

-----
timing summary (100k lines each)
-----
print                         : 2.920 s
write to file (+fsync)        : 0.121 s
print with stdout = /dev/null : 0.048 s

এটি অবশ্যই ভাল (4x ডলার), তবে আমার প্রশ্ন পরিবর্তন করে না। এটা শুধুমাত্র যোগ করা আমার প্রশ্নের যেমন আমি বুঝতে পারছি না কেন টার্মিনাল পর্দা রেন্ডারিং একটি অ্যাপ্লিকেশন stdout- এ লেখা মন্দীভূত করা উচিত নয়। আমার প্রোগ্রামটি কেন চালিয়ে যাওয়ার জন্য পর্দার রেন্ডারিংয়ের জন্য অপেক্ষা করতে হবে?

সমস্ত টার্মিনাল / টিটি অ্যাপ্লিকেশন কি সমানভাবে তৈরি হয় না? আমার এখনও পরীক্ষা-নিরীক্ষা বাকি আছে। এটি আমার কাছে সত্যই মনে হয় যেমন টার্মিনালটি সমস্ত আগত তথ্য বাফার করতে পারে, অদৃশ্যভাবে এটিকে পার্স / রেন্ডার করতে পারে এবং কেবলমাত্র বর্তমান স্ক্রিন কনফিগারেশনে দৃশ্যমান একটি সাম্প্রতিক ফ্রেমের হারে সাম্প্রতিকতম অংশটি রেন্ডার করতে পারে। সুতরাং আমি যদি ০.০ সেকেন্ডের মধ্যে ডিস্কে + fsync লিখতে পারি তবে একটি টার্মিনাল সেই ক্রমের কিছুতে একই ক্রিয়াকলাপটি সম্পন্ন করতে সক্ষম হবে (এটি করার সময় কয়েকটি স্ক্রিন আপডেট থাকতে পারে)।

আমি এখনও একধরণের আশা করছি এমন একটি টিটিটি সেটিং রয়েছে যা প্রোগ্রামারটির জন্য এই আচরণটি আরও ভাল করার জন্য অ্যাপ্লিকেশন দিক থেকে পরিবর্তন করা যেতে পারে। এটি যদি কঠোরভাবে কোনও টার্মিনাল অ্যাপ্লিকেশন সমস্যা হয় তবে এটি সম্ভবত স্ট্যাকওভারফ্লোতেও অন্তর্ভুক্ত নয়?

আমি কী মিস করছি?


সময় উৎপাদনের জন্য ব্যবহৃত পাইথন প্রোগ্রামটি এখানে:

import time, sys, tty
import os

lineCount = 100000
line = "this is a test"
summary = ""

cmd = "print"
startTime_s = time.time()
for x in range(lineCount):
    print line
t = time.time() - startTime_s
summary += "%-30s:%6.3f s\n" % (cmd, t)

#Add a newline to match line outputs above...
line += "\n"

cmd = "write to file (+fsync)"
fp = file("out.txt", "w")
startTime_s = time.time()
for x in range(lineCount):
    fp.write(line)
os.fsync(fp.fileno())
t = time.time() - startTime_s
summary += "%-30s:%6.3f s\n" % (cmd, t)

cmd = "print with stdout = /dev/null"
sys.stdout = file(os.devnull, "w")
startTime_s = time.time()
for x in range(lineCount):
    fp.write(line)
t = time.time() - startTime_s
summary += "%-30s:%6.3f s\n" % (cmd, t)

print >> sys.stderr, "-----"
print >> sys.stderr, "timing summary (100k lines each)"
print >> sys.stderr, "-----"
print >> sys.stderr, summary

9
স্টাডাউটে লেখার পুরো উদ্দেশ্যটি তাই কোনও মানুষ আউটপুটটি পড়তে পারে। পৃথিবীর কোনও মানুষই 12 সেকেন্ডে 10,000 লাইন পাঠ্য পাঠ করতে পারে না, তাই স্টডআউটকে দ্রুত তৈরি করার কী দরকার ???
Seun Osewa

14
@Seun Osewa: একটা উদাহরণ (যে আমার প্রশ্নের ঘটেছে) যখন ভালো জিনিস করছেন মুদ্রণ বিবৃতি ডিবাগিং । আপনি আপনার প্রোগ্রামটি চালাতে চান এবং ফলাফলগুলি যেমন ঘটে থাকে তেমন দেখতে চান। আপনি স্পষ্টতই ঠিক বলেছেন যে বেশিরভাগ লাইনগুলি আপনি দেখতে পাচ্ছেন না সেখান দিয়ে উড়ে যাবে, তবে যখন কোনও ব্যতিক্রম ঘটে (বা আপনি শর্তযুক্ত গ্যাচ / কাঁচা-ইনপুট / স্লিপ স্টেটমেন্টটি আপনি সাবধানে রেখেছিলেন) তখন আপনি মুদ্রণের আউটপুটটি সরাসরি তাকানোর চেয়ে দেখতে চান ক্রমাগত একটি ফাইল ভিউ খুলতে বা রিফ্রেশ করতে হবে।
রাশ

3
প্রিন্ট স্টেটমেন্ট ডিবাগিং হ'ল ব্লফ বাফারিংয়ের পরিবর্তে ডিফল্ট ডিফল্টগুলি (অর্থাত্ টার্মিনালগুলি) লাইন বাফারিংয়ের ডিফল্ট হওয়ার কারণগুলির মধ্যে একটি: প্রোগ্রামটি যদি স্তব্ধ হয়ে থাকে এবং ডিবাগ আউটপুটটির শেষ কয়েকটি লাইন এখনও বাফারে থাকে তবে ডিবাগ আউটপুট বেশি ব্যবহার হয় না পরিবর্তে টার্মিনালে ফ্লাশ করা।
স্টিফেন সি স্টিল 21

@ স্টেফেন: এই কারণেই বাফারের আকার ক্র্যাঙ্ক করে একজন মন্তব্যকারী দাবি করেছেন যে বিশাল উন্নতি সাধনের জন্য আমি খুব একটা মাথা ঘামাইনি। এটি সম্পূর্ণরূপে ডিবাগ প্রিন্টিংয়ের উদ্দেশ্যকে পরাস্ত করে! তদন্ত করার সময় আমি কিছুটা পরীক্ষা-নিরীক্ষা করেছিলাম, তবে নেট উন্নতি দেখতে পাইনি। আমি তফাত সম্পর্কে এখনও কৌতূহল, কিন্তু আসলে না।
রাশ

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

উত্তর:


155

এটি কীভাবে হতে পারে যে শারীরিক ডিস্কে লেখা "স্ক্রিনে" লেখার চেয়ে সম্ভবত দ্রুত (সম্ভবত একটি অল-র‍্যাম বিকল্প), এবং কার্যকরভাবে / দেব / নাল দিয়ে আবর্জনায় ফেলে দেওয়ার মতো কার্যকর?

অভিনন্দন, আপনি সবেমাত্র I / O বাফারিংয়ের গুরুত্ব আবিষ্কার করেছেন। :-)

ডিস্কটি দ্রুততর বলে মনে হচ্ছে , কারণ এটি অত্যন্ত বাফার হয়েছে: write()আসলে পাইথনের সমস্ত কল ফিজিক্যাল ডিস্কে কিছু লেখার আগেই ফিরে আসবে। (ওএস পরে এটি করে, হাজার হাজার স্বতন্ত্র লেখার সমন্বয়ে একটি বৃহত, দক্ষ খণ্ডে রচনা করে))

অন্যদিকে টার্মিনালটি খুব কম বা কোনও বাফারিং করে না: প্রতিটি ব্যক্তি print/ সম্পূর্ণ লেখার write(line)জন্য অপেক্ষা করে (যেমন আউটপুট ডিভাইসে প্রদর্শিত হয়) সম্পূর্ণ হয়।

তুলনা সুষ্ঠু করার জন্য, আপনাকে অবশ্যই ফাইল টেস্টটিকে টার্মিনালের মতো একই আউটপুট বাফারিং ব্যবহার করতে হবে, যা আপনি এখানে নিজের উদাহরণটি পরিবর্তন করে করতে পারেন:

fp = file("out.txt", "w", 1)   # line-buffered, like stdout
[...]
for x in range(lineCount):
    fp.write(line)
    os.fsync(fp.fileno())      # wait for the write to actually complete

আমি আমার মেশিনে আপনার ফাইল রাইটিং পরীক্ষাটি চালিয়েছি, এবং বাফারিংয়ের মাধ্যমে এটি এখানে 100,000 লাইনের জন্য 0.05 সেকেন্ডে রয়েছে।

যাইহোক, উপরোক্ত পরিবর্তনগুলি আনফার্ড না করে লিখতে, ডিস্কে কেবলমাত্র 1000 লাইন লিখতে 40 সেকেন্ড সময় লাগে। আমি লিখতে 100,000 লাইন অপেক্ষা করে ছেড়ে দিয়েছিলাম, তবে পূর্বের থেকে এক্সট্রাপোলেটিং করতে এটি এক ঘন্টা সময় নিতে পারে

এটি টার্মিনালের 11 সেকেন্ডকে দৃষ্টিকোণে ফেলেছে, তাই না?

সুতরাং আপনার মূল প্রশ্নের উত্তর দেওয়ার জন্য, একটি টার্মিনালে লেখার বিষয়টি নির্লজ্জভাবে দ্রুত, সমস্ত বিষয় বিবেচনা করা হয় এবং এটিকে আরও দ্রুত করার জন্য খুব বেশি জায়গা নেই (তবে স্বতন্ত্র টার্মিনালগুলি তারা কতটা কাজ করে তার চেয়ে আলাদা হয়; এতে রাশিয়ার মন্তব্য দেখুন উত্তর).

(আপনি ডিস্ক আই / ও এর মতো আরও লিখিত বাফারিং যুক্ত করতে পারেন, তবে বাফারটি ফ্লাশ হওয়ার পরে আপনি আপনার টার্মিনালে কী লেখা ছিল তা দেখতে পাবেন না It's এটি একটি বাণিজ্য-বন্ধ: আন্তঃব্যবহারতা বনাম বাল্ক দক্ষতা))


6
আমি / হে বাফারিং পেয়েছি ... আপনি অবশ্যই আমাকে মনে করিয়ে দিয়েছেন যে সমাপ্তির সময়টির সত্যিকারের তুলনা করার জন্য আমার মায়াময় হওয়া উচিত (আমি প্রশ্নটি আপডেট করব), তবে প্রতি লাইনে একটি ফ্যানসিঙ্ক হ'ল উন্মাদনা। একটি tty সত্যিই কার্যকরভাবে এটি করা প্রয়োজন? ফাইলগুলির সমতুল্য কোনও টার্মিনাল / ওএস-সাইড বাফারিং নেই? উদাহরণস্বরূপ: অ্যাপ্লিকেশনগুলি stdout এ লিখুন এবং টার্মিনালটি স্ক্রিনে রেন্ডার করার আগে ফিরে আসে, টার্মিনাল (বা ওএস) এর সাথে সমস্ত কিছু বাফার করে। টার্মিনালটি তখন বোধগম্যভাবে একটি দৃশ্যমান ফ্রেমের হারে লেজটিকে স্ক্রিনে রেন্ডার করে। কার্যকরভাবে প্রতিটি লাইনে ব্লক করা নির্বোধ বলে মনে হয়। আমার মনে হচ্ছে আমি এখনও কিছু মিস করছি।
রাশ

আপনি নিজের মতো একটি বড় বাফার দিয়ে স্টাডাউট করতে কেবল একটি হ্যান্ডেল খুলতে পারেন, এর মতো কিছু ব্যবহার করে os.fdopen(sys.stdout.fileno(), 'w', BIGNUM)। এটি প্রায়শই কার্যকর হবে না, যদিও: প্রায় সমস্ত অ্যাপ্লিকেশনকে ব্যবহারকারী-উদ্দেশ্যযুক্ত আউটপুটটির প্রতিটি লাইন পরে স্পষ্টভাবে ফ্লাশ করতে হবে।
পাই ডিলপোর্ট 21

1
আমি fp = os.fdopen(sys.__stdout__.fileno(), 'w', 10000000)অজগর-পাশের বাফারগুলির সাথে বিশাল (10MB অবধি ) সাথে পরীক্ষা করেছিলাম । প্রভাব শূন্য ছিল। যেমন: এখনও দীর্ঘ tty বিলম্ব। এটি আমাকে ভাবতে / অনুধাবন করতে পেরেছিল যে আপনি কেবল ধীর tty সমস্যা স্থগিত করেছেন ... শেষ অবধি পাইথনের বাফার টিটিটি প্রবাহিত হওয়ার আগে প্রবাহে একই পরিমাণে একই পরিমাণে প্রসেসিংয়ের মতো বলে মনে হচ্ছে।
রাশ

8
মনে রাখবেন যে এই উত্তরটি বিভ্রান্তিমূলক এবং ভুল (দুঃখিত!)। বিশেষত "এটি দ্রুত করার জন্য খুব বেশি জায়গা নেই [11 সেকেন্ডের চেয়ে বেশি]" বলা ভুল। দয়া করে আমি যেখানে প্রশ্নের উত্তর দিয়েছি তার নিজের উত্তরটি দেখুন যেখানে ডাব্লামটার্ন টার্মিনাল 0.26 এর দশকে একই 11 এর ফলাফল অর্জন করেছে।
রাশ

2
রাশ: প্রতিক্রিয়া জন্য ধন্যবাদ! আমার পক্ষে, একটি বৃহত্তর fdopenবাফার (2 এমবি) অবশ্যই একটি বিশাল পার্থক্য করেছে: এটি মুদ্রণের সময়টিকে অনেক সেকেন্ড থেকে 0.05 সেকেন্ডে নামিয়েছিল, ফাইল আউটপুট (ব্যবহার করে gnome-terminal) এর মতো।
পাই ডিলপোর্ট

88

সব মন্তব্যের জন্য ধন্যবাদ! আপনার সাহায্যে আমি নিজেই এর উত্তর দিয়েছি। যদিও আপনার নিজের প্রশ্নের উত্তর দেওয়াটা নোংরা লাগে।

প্রশ্ন 1: stdout থেকে মুদ্রণ কেন ধীর?

উত্তর: স্টাডাউটে মুদ্রণ সহজাতভাবে ধীর হয় না । এটি আপনি যে টার্মিনালটির সাথে কাজ করছেন তা ধীর। এবং অ্যাপ্লিকেশন পক্ষের আই / ও বাফারিংয়ের সাথে এটি করার শূন্যতা রয়েছে (যেমন: পাইথন ফাইল বাফারিং)। নিচে দেখ.

প্রশ্ন 2: এটি গতিময় হতে পারে?

উত্তর: হ্যাঁ এটি পারে, তবে দৃশ্যমানভাবে প্রোগ্রামের পক্ষ থেকে নয় (পক্ষটি 'প্রিন্টিং' স্টাডআউট করছে)। এটির গতি বাড়ানোর জন্য, একটি দ্রুত ভিন্ন টার্মিনাল এমুলেটর ব্যবহার করুন।

ব্যাখ্যা ...

আমি স্ব-বর্ণিত 'লাইটওয়েট' টার্মিনাল প্রোগ্রামটি চেষ্টা করেছি wtermএবং উল্লেখযোগ্যভাবে আরও ভাল ফলাফল পেয়েছি । নীচে আমার পরীক্ষার স্ক্রিপ্টের আউটপুট (প্রশ্নের নীচে) wterm1920x1200 এ একই সিস্টেমে চলার সময় যেখানে বেসিক প্রিন্ট বিকল্পটি জিনোম-টার্মিনাল ব্যবহার করে 12 সেকেন্ড নিয়েছিল:

-----
সময় সংক্ষিপ্তসার (প্রতিটি 100k লাইন)
-----
মুদ্রণ: 0.261 এস
ফাইল লিখুন (+ fsync): 0.110 এস
stdout = / dev / নাল: 0.050 গুলি সহ মুদ্রণ করুন

0.26s 12s এর চেয়ে অনেক বেশি ভাল! আমি জানি না যে wtermএটি কীভাবে আমি পরামর্শ দিচ্ছিলাম (যেভাবে একটি ফ্রেম রেটে 'দৃশ্যমান' লেজটি রেন্ডার করুন) তার পর্দাতে কীভাবে রেন্ডার দেয় সে সম্পর্কে আরও বুদ্ধিমান কিনা, বা এটি কেবল "কম" করে কিনা gnome-terminal। আমার প্রশ্নের প্রয়োজনে আমি উত্তর পেয়েছি, যদিও। gnome-terminalধীর.

সুতরাং - আপনার যদি দীর্ঘ চলমান স্ক্রিপ্ট থাকে যা আপনি ধীর বলে মনে করেন এবং এটি প্রচুর পরিমাণে পাঠ্যকে স্টাডাউট করে তোলে ... একটি ভিন্ন টার্মিনাল চেষ্টা করে দেখুন এটি আরও ভাল কিনা!

মনে রাখবেন যে আমি wtermউবুন্টু / ডিবিয়ান সংগ্রহস্থলগুলি থেকে এলোমেলোভাবে টানছি। এই লিঙ্কটি একই টার্মিনাল হতে পারে, তবে আমি নিশ্চিত নই। আমি অন্য কোনও টার্মিনাল এমুলেটর পরীক্ষা করিনি।


আপডেট: যেহেতু আমাকে চুলকানি স্ক্র্যাচ করতে হয়েছিল, আমি একই স্ক্রিপ্ট এবং পূর্ণ স্ক্রিন (1920x1200) সহ অন্যান্য টার্মিনাল এমুলেটরগুলির পুরো গাদা পরীক্ষা করেছি। আমার ম্যানুয়ালি সংগৃহীত পরিসংখ্যানগুলি এখানে:

wterm 0.3s
অটারেম 0.3s
rxvt 0.3s
mrxvt 0.4s
কনসোল 0.6 এস
ইয়াকুকে 0.7s
lxterminal 7s
এক্সটার্ম 9 এস
জিনোম-টার্মিনাল 12 এস
xfce4- টার্মিনাল 12s
ভালা-টার্মিনাল 18s
xvt 48s

রেকর্ড করা সময়গুলি ম্যানুয়ালি সংগ্রহ করা হয় তবে সেগুলি বেশ সামঞ্জস্যপূর্ণ ছিল। আমি সেরা (ইশ) মান রেকর্ড করেছি। ওয়াইএমএমভি, স্পষ্টতই।

বোনাস হিসাবে, এটি সেখানে উপলব্ধ বিভিন্ন টার্মিনাল এমুলেটরগুলির একটি আকর্ষণীয় ভ্রমণ ছিল! আমি আমার প্রথম 'বিকল্প' পরীক্ষাটি গুচ্ছের সেরা হতে দেখলাম।


1
আপনি অ্যালার্ম চেষ্টা করতে পারেন। আপনার স্ক্রিপ্টটি ব্যবহার করে আমার পরীক্ষার ফলাফলগুলি এখানে। অ্যালার্ম - মুদ্রণ: 0.491 গুলি, ফাইলটিতে লিখুন (+ fsync): 0.110 গুলি, স্ট্যান্ডআউট = / দেব / নাল দিয়ে প্রিন্ট করুন: 0.087 s wterm - মুদ্রণ: 0.521 এস, ফাইলটিতে লিখুন (+ fsync): 0.105 s, স্টাডআউট সহ মুদ্রণ = / দেব / নাল: 0.085 গুলি
ব্যাঙ স্টায়ার Oct৮

1
Urxvt কীভাবে rxvt এর সাথে তুলনা করে?
দেনিথ

3
এছাড়াও, screen(প্রোগ্রাম) তালিকায় অন্তর্ভুক্ত করা উচিত! (বা byobu, যা screenবর্ধনের জন্য একটি মোড়ক ) এই ইউটিলিটিটি বেশ কয়েকটি টার্মিনাল রাখতে দেয়, অনেকটা এক্স টার্মিনালের ট্যাবের মতো। আমি অনুমান করি যে বর্তমানের screenটার্মিনালে মুদ্রণ একটি সমতল প্রিন্টিংয়ের সমান, তবে screenকোনওটির টার্মিনালে মুদ্রণ এবং তারপরে কোনও ক্রিয়াকলাপ না করে অন্যটিতে স্যুইচ করা কী?
আরমান্ডো পেরেজ মার্কেজ

1
অদ্ভুত, কিছু সময় আগে আমি গতির দিক দিয়ে বিভিন্ন টার্মিনালগুলির সাথে তুলনা করছিলাম এবং জিনোম-টার্মিনালটি গুরুতর পরীক্ষাগুলিতে সেরাভাবে বেরিয়ে এসেছিল যখন এক্সটার্ম সবচেয়ে ধীর ছিল। সম্ভবত তারা তখন থেকেই বাফারিংয়ের জন্য কঠোর পরিশ্রম করেছিল। এছাড়াও ইউনিকোড সমর্থন একটি বড় পার্থক্য করতে পারে।
টমাস প্রুজিনা

2
iTerm2 উপর ওএসএক্স আমাকে দিয়েছে: print: 0.587 s, write to file (+fsync): 0.034 s, print with stdout = /dev/null : 0.041 s। এবং 'স্ক্রিন' print: 1.286 s, write to file (+fsync): 0.043 s, print with stdout = /dev/null : 0.033 s
আইটির্ম 2

13

প্রোগ্রামগুলি তাদের আউটপুট এফডিটি কোনও টিটি-তে নির্দেশ করে কিনা তা নির্ধারণ করতে পারার কারণে আপনার পুনঃনির্দেশ সম্ভবত সম্ভবত কিছুই করে না।

এটি সম্ভবত টার্মিনাল (সি এর stdoutস্ট্রিম আচরণের সমান ) দিকে ইশারা করার সময় stdout লাইন বাফার হয় ।

একটি মজাদার পরীক্ষা হিসাবে, আউটপুটটি এখানে পাইপ করার চেষ্টা করুন cat


আমি আমার নিজের চিত্তাকর্ষক পরীক্ষা করে দেখেছি এবং ফলাফল এখানে।

$ python test.py 2>foo
...
$ cat foo
-----
timing summary (100k lines each)
-----
print                         : 6.040 s
write to file                 : 0.122 s
print with stdout = /dev/null : 0.121 s

$ python test.py 2>foo |cat
...
$ cat foo
-----
timing summary (100k lines each)
-----
print                         : 1.024 s
write to file                 : 0.131 s
print with stdout = /dev/null : 0.122 s

অজগরটির আউটপুট এফএস চেক করার কথা ভাবিনি। আমি ভাবছি অজগর যদি পর্দার আড়ালে কোনও কৌশল টানছে? আমি আশা করি না, তবে জানি না।
রাশ

বাফারিংয়ে সর্বাত্মক পার্থক্যটি চিহ্নিত করার জন্য +1
পিটার জি।

@Russ: -uবিকল্প বাহিনী stdin, stdoutএবং stderrunbuffered হতে, যা হচ্ছে (ওভারহেড কারণে) বাফার ব্লক তুলনায় ধীর হতে হবে
Hasturkun

4

আমি প্রযুক্তিগত বিবরণ সম্পর্কে কথা বলতে পারি না কারণ আমি সেগুলি জানি না, তবে এটি আমাকে অবাক করে না: টার্মিনালটি এই জাতীয় প্রচুর ডেটা মুদ্রণের জন্য ডিজাইন করা হয়নি। প্রকৃতপক্ষে, আপনি এমনকি জিইআইআই স্টাডগুলির একটি লোডের একটি লিঙ্ক সরবরাহ করেন যা প্রতিবার আপনি কিছু মুদ্রণ করতে চাইলে তা করতে হয়! লক্ষ্য করুন যে আপনি যদি pythonwপরিবর্তে স্ক্রিপ্টটি কল করেন তবে এটি 15 সেকেন্ড সময় নেয় না; এটি পুরোপুরি জিইউআই ইস্যু। stdoutএটি এড়াতে কোনও ফাইলে পুনর্নির্দেশ করুন :

import contextlib, io
@contextlib.contextmanager
def redirect_stdout(stream):
    import sys
    sys.stdout = stream
    yield
    sys.stdout = sys.__stdout__

output = io.StringIO
with redirect_stdout(output):
    ...

3

টার্মিনালে মুদ্রণ ধীর হতে চলেছে। দুর্ভাগ্যক্রমে একটি নতুন টার্মিনাল বাস্তবায়ন লেখার সংক্ষেপে আমি সত্যিই দেখতে পাচ্ছি না আপনি কীভাবে এটির গতি বাড়িয়ে তুলবেন।


2

লাইন-বাফার মোডে সম্ভবত ডিফল্ট আউটপুট ছাড়াও, একটি টার্মিনালে আউটপুট আপনার ডেটা টার্মিনাল এবং সিরিয়াল লাইনে সর্বাধিক থ্রুপুট, বা সিউডো-টার্মিনাল এবং একটি পৃথক প্রক্রিয়া যা ডিসপ্লে পরিচালনা করছে is ইভেন্ট লুপ, কিছু ফন্ট থেকে অক্ষরগুলি রেন্ডারিং, কোনও স্ক্রোলিং ডিসপ্লে বাস্তবায়নের জন্য ডিসপ্লে বিটগুলি সরানো। পরবর্তী পরিস্থিতি সম্ভবত একাধিক প্রক্রিয়াতে ছড়িয়ে রয়েছে (যেমন টেলনেট সার্ভার / ক্লায়েন্ট, টার্মিনাল অ্যাপ্লিকেশন, এক্স 11 ডিসপ্লে সার্ভার) সুতরাং প্রসঙ্গের স্যুইচিং এবং বিলম্বিত সমস্যাগুলিও রয়েছে।


সত্য! এটি আমাকে আমার টার্মিনাল উইন্ডোর আকারকে (জিনোমে) কিছুটা পাণি (1920x1200 থেকে) হ্রাস করার চেষ্টা করতে অনুরোধ করেছিল। অবশ্যই যথেষ্ট ... ২.৮ এস মুদ্রণের সময় বনাম ১১.৫ এস আরও ভাল, কিন্তু এখনও ... এটি স্টলিং কেন? আপনি ভাবেন যে স্টডআউট বাফার (এইচএমএম) সমস্ত 100 কে লাইন পরিচালনা করতে পারে এবং টার্মিনাল ডিসপ্লেটি এটি বাফারের লেজের প্রান্ত থেকে স্ক্রিনে ফিট করতে পারে এবং এটি একটি দ্রুত শটে সম্পন্ন করবে।
রাশ

এক্সটার্ম (বা gterm, এক্ষেত্রে) আপনার চূড়ান্ত স্ক্রিনটি দ্রুত সরবরাহ করবে যদি মনে না করে যে এটির পাশাপাশি অন্যান্য আউটপুটগুলিরও প্রদর্শন করতে হবে। যদি এই রুটে যাওয়ার চেষ্টা করা হয় তবে এটি সম্ভবত ছোট পর্দার আপডেটগুলির সাধারণ কেসটিকে কম প্রতিক্রিয়াযুক্ত বলে মনে করবে। এই ধরণের সফ্টওয়্যারটি লেখার সময় আপনি মাঝে মাঝে বিভিন্ন মোড রেখে এবং যখন আপনাকে ছোট থেকে বাল্ক মোড অপারেশনে যেতে হবে তখন এটি সনাক্ত করার চেষ্টা করে এটি মোকাবেলা করতে পারেন। আপনি এই গতি বাড়ানোর জন্য cat big_file | tailবা এমনকি cat big_file | tee big_file.cpy | tailপ্রায়শই ব্যবহার করতে পারেন ।
শ্রেণীবদ্ধ 21
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.