ফাইলের… লম্বা বা লেজের প্রথম লাইনটি মুছতে কোনটি দ্রুত?

Question

এই উত্তরে ( আমি শেডযুক্ত কোনও ফাইলের প্রথম লাইনটি কীভাবে সরিয়ে ফেলব? ) কোনও ফাইলের প্রথম রেকর্ডটি মোছার দুটি উপায় রয়েছে:

sed '1d' $file >> headerless.txt

** ---------------- বা ---------------- **

tail -n +2 $file >> headerless.txt

ব্যক্তিগতভাবে আমি মনে করি tailবিকল্পটি কসমেটিক্যালি আরও আনন্দদায়ক এবং আরও পঠনযোগ্য তবে সম্ভবত সেড-চ্যালেঞ্জযুক্ত।

কোন পদ্ধতিটি দ্রুততম?

Comments

কোনও উত্তর নয়, তবে সম্ভাব্য sedবিবেচনাটি হ'ল আরও পোর্টেবল: "+2" tailউবুন্টুতে ভাল কাজ করার জন্য , যা জিএনইউ ব্যবহার করে tail, তবে বিএসডি-তে কাজ করবে না tail।

— জন এন

tailক্রস প্ল্যাটফর্মের সামঞ্জস্যতার অভাব ভাগ করে নেওয়ার জন্য @ জনএন ধন্যবাদ thanks

— WinEunuuchs2Unix

লেজুতে "জন এন" +২ "সিয়ারার ম্যাক চলমান ম্যাকের উপর দারুণভাবে কাজ করে যা বিএসডি টেইল কমান্ডটি ব্যবহার করে বলে দাবি করেছে

— নিক সিলিটো

উরগ, আপনি একদম ঠিক বলেছেন - আমি কেবল এটি আবার চালিয়েছি এবং এবার ইনপুটটি পরীক্ষা করে দেখলাম। যা আমার প্রথমবার করা উচিত ছিল। এটাও পসিক্স। / পিছলে যায়, বিব্রত।

— জন এন

@ জনএনএন আপনি সম্পূর্ণ ভুল নন অতীতে, ইউএনআইএক্স -nবিকল্প সরবরাহ করে নি, এবং সিনট্যাক্সটি ব্যবহার করেছিল tail +2 $file। Freebsd.org/cgi/… দেখুন আপনি আধুনিক বিএসডিগুলির পরিবর্তে এটির বিষয়ে ভাবছিলেন।

— এইচডিভি

Answer 1

কোনও ফাইলের প্রথম লাইন অপসারণ করতে sedবনামের পারফরম্যান্সtail

টি এল; ডিআর

• sed খুব শক্তিশালী এবং বহুমুখী, তবে এটি এটিকে ধীর করে তোলে বিশেষত অনেকগুলি লাইনযুক্ত বড় ফাইলগুলির জন্য।

• tail কেবল একটি সাধারণ কাজ করে তবে এটি একটি ভাল এবং দ্রুত করে তোলে এমনকি অনেকগুলি লাইনযুক্ত বড় ফাইলগুলির জন্য।

ছোট এবং মাঝারি আকারের ফাইলগুলির জন্য sedএবং tailএকই ধরণের দ্রুত সঞ্চালন করছে (বা ধীর আপনার প্রত্যাশার উপর নির্ভর করে)। তবে বৃহত্তর ইনপুট ফাইলগুলির জন্য (একাধিক এমবি), পারফরম্যান্সের পার্থক্যটি উল্লেখযোগ্যভাবে বৃদ্ধি পায় (শত শত এমবি'র সীমাতে থাকা ফাইলগুলির আকারের ক্রম), tailপরিষ্কারভাবে ছাড়িয়ে যায় sed।

পরীক্ষা

সাধারণ প্রস্তুতি:

বিশ্লেষণ করার জন্য আমাদের আদেশগুলি হল:

sed '1d' testfile > /dev/null
tail -n +2 testfile > /dev/null

নোট করুন যে আমি /dev/nullটার্মিনাল আউটপুট বা ফাইলটি সম্পাদনের জন্য প্রতিবার আউটপুটটি পাইপ করছি পারফরম্যান্সের বাধা হিসাবে writes

আসুন ডিস্ক I / O কে সম্ভাব্য বিঘ্ন হিসাবে অপসারণ করতে একটি র‌্যাম ডিস্ক সেট আপ করুন। আমি ব্যক্তিগতভাবে একটি tmpfsমাউন্ট করা আছে /tmpতাই আমি কেবল testfileএই পরীক্ষার জন্য আমার সেখানে রেখেছি ।

তারপরে আমি একবার $numoflinesএই কমান্ডটি ব্যবহার করে এলোমেলো লাইন দৈর্ঘ্য এবং এলোমেলো তথ্য সহ নির্দিষ্ট পরিমাণ রেখাসমূহ সহ একটি র‌্যান্ডম টেস্ট ফাইল তৈরি করছি (নোট করুন এটি অবশ্যই সর্বোত্তম নয়, এটি>> 2 এম লাইনের জন্য সত্যই ধীর হয়ে যায়, তবে কে পাত্তা দেয় তা নয়) আমরা যা বিশ্লেষণ করছি):

cat /dev/urandom | base64 -w0 | tr 'n' '\n'| head -n "$numoflines" > testfile

ওহ, বিটিডব্লিউ আমার পরীক্ষার ল্যাপটপটি ইন্টেল i5-6200U সিপিইউতে উবুন্টু 16.04, 64 বিট চালাচ্ছে। শুধু তুলনার জন্য।

বড় ফাইলগুলির সময় নির্ধারণ:

একটি বিশাল সেট আপ করা testfile:

উপরের কমান্ডটি চালানো numoflines=1000000010 এম লাইন সমন্বিত একটি এলোমেলো ফাইল তৈরি করেছে, 600 এমবি থেকে কিছুটা দখল করে - এটি বেশ বিশাল, তবে আসুন এটি দিয়ে শুরু করা যাক আমরা পারি:

$ wc -l testfile 
10000000 testfile

$ du -h testfile 
611M    testfile

$ head -n 3 testfile 
qOWrzWppWJxx0e59o2uuvkrfjQbzos8Z0RWcCQPMGFPueRKqoy1mpgjHcSgtsRXLrZ8S4CU8w6O6pxkKa3JbJD7QNyiHb4o95TSKkdTBYs8uUOCRKPu6BbvG
NklpTCRzUgZK
O/lcQwmJXl1CGr5vQAbpM7TRNkx6XusYrO

আমাদের বিশাল সাথে সময়োচিত রান সম্পাদন করুন testfile:

প্রথমে আমরা কী বিস্তৃতি নিয়ে কাজ করছি তা অনুমান করার জন্য প্রথমে উভয় কমান্ডের সাথে একটিমাত্র সময়সীমার চালানো যাক।

$ time sed '1d' testfile > /dev/null
real    0m2.104s
user    0m1.944s
sys     0m0.156s

$ time tail -n +2 testfile > /dev/null
real    0m0.181s
user    0m0.044s
sys     0m0.132s

আমরা বড় ফাইলগুলির জন্য ইতিমধ্যে একটি স্পষ্ট ফলাফল দেখতে পাচ্ছি, এর tailচেয়ে তাত্পর্যপূর্ণ sed। তবে কেবল মজাদার জন্য এবং এটির জন্য নিশ্চিত যে কোনও এলোমেলো পার্শ্ব প্রতিক্রিয়া বড় পার্থক্য করছে না, আসুন এটি 100 বার করুন:

$ time for i in {1..100}; do sed '1d' testfile > /dev/null; done
real    3m36.756s
user    3m19.756s
sys     0m15.792s

$ time for i in {1..100}; do tail -n +2 testfile > /dev/null; done
real    0m14.573s
user    0m1.876s
sys     0m12.420s

উপসংহারটি একই থাকে, sedবড় ফাইলের প্রথম লাইন অপসারণ করতে অক্ষম, tailসেখানে ব্যবহার করা উচিত।

এবং হ্যাঁ, আমি জানি বাশের লুপের নির্মাণগুলি ধীর গতিতে রয়েছে তবে আমরা এখানে তুলনামূলকভাবে কয়েকটি পুনরাবৃত্তি করছি এবং যে কোনও সময় প্লে লুপ সময় নেয় তা sed/ tailরানটাইমের তুলনায় তাত্পর্যপূর্ণ নয় ।

ছোট ফাইলগুলির সময় নির্ধারণ:

একটি ছোট সেট আপ testfile:

সম্পূর্ণতার জন্য, আসুন আমরা আপনার কেবি রেঞ্জের একটি ছোট ইনপুট ফাইল রয়েছে এমন আরও সাধারণ ক্ষেত্রে লক্ষ্য করি। এর মতো দেখতে একটি এলোমেলো ইনপুট ফাইল তৈরি করা যাক numoflines=100:

$ wc -l testfile 
100 testfile

$ du -h testfile 
8,0K    testfile

$ head -n 3 testfile 
tYMWxhi7GqV0DjWd
pemd0y3NgfBK4G4ho/
aItY/8crld2tZvsU5ly

আমাদের ছোট দিয়ে সময়োচিত রান করুন testfile:

যেহেতু আমরা আশা করতে পারি যে এই জাতীয় ছোট ফাইলগুলির সময় অভিজ্ঞতা থেকে কয়েক মিলিসেকেন্ডের মধ্যে থাকে, আসুন এখনই 1000 টি পুনরাবৃত্তি করা যাক:

$ time for i in {1..1000}; do sed '1d' testfile > /dev/null; done
real    0m7.811s
user    0m0.412s
sys     0m7.020s

$ time for i in {1..1000}; do tail -n +2 testfile > /dev/null; done
real    0m7.485s
user    0m0.292s
sys     0m6.020s

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

Comments

আপনাকে উত্তর দেওয়ার জন্য +1। আমি সার্জের মন্তব্যের ভিত্তিতে মূল প্রশ্নটি (দুঃখিত) সম্পাদনা করেছি যা awkএটিও করতে পারে। আমার আসল প্রশ্নটি আমি প্রথম স্থানে যে লিঙ্কটি পেয়েছি তার উপর ভিত্তি করে ছিল। আপনার সমস্ত কঠোর পরিশ্রমের পরে দয়া করে আমাকে পরামর্শ awkপ্রার্থী হিসাবে অপসারণ করা উচিত এবং কেবল sedএবং এর মূল প্রকল্পের স্কোপে ফোকাস ফিরিয়ে দেওয়া উচিত কিনা তা পরামর্শ করুন tail।

— WinEunuuchs2Unix

এটা কি সিস্টেম? আমার ম্যাক (সুতরাং বিএসডি সরঞ্জামসমূহ) এ, / usr / share / ডিক / শব্দের উপর পরীক্ষা করা আমাকে সেডের জন্য 0.09s এবং লেজের জন্য 0.19s দেয় (এবং awk 'NR > 1'আকর্ষণীয়ভাবে)।

— কেভিন

Answer 2

এখানে কেবল বিকল্প বিল্টিনগুলি ব্যবহার করে এবং অন্য বিকল্প রয়েছে cat:

{ read ; cat > headerless.txt; } < $file

$file{ }কমান্ড গ্রুপিং এ পুনঃনির্দেশিত হয় । readকেবল পড়ে এবং প্রথম লাইন বর্জন করা হয়। স্ট্রিমের বাকী অংশটি তারপরে পাইপ করা হয় catযা এটি গন্তব্য ফাইলে লিখে।

আমার উবুন্টু 16.04 এ এর ​​কার্য সম্পাদন এবং tailসমাধানটি খুব মিল। আমি এর সাথে একটি লার্জিশ টেস্ট ফাইল তৈরি করেছি seq:

$ seq 100000000 > 100M.txt
$ ls -l 100M.txt 
-rw-rw-r-- 1 ubuntu ubuntu 888888898 Dec 20 17:04 100M.txt
$

tail সমাধান:

$ time tail -n +2 100M.txt > headerless.txt

real    0m1.469s
user    0m0.052s
sys 0m0.784s
$ 

cat/ ব্রেস সমাধান:

$ time { read ; cat > headerless.txt; } < 100M.txt 

real    0m1.877s
user    0m0.000s
sys 0m0.736s
$ 

আমি এখনই কেবল একটি উবুন্টু ভিএম হ্যান্ডি পেয়েছি এবং উভয়ের সময়কালে উল্লেখযোগ্য পার্থক্য দেখেছি, যদিও তারা সবাই একই বলপার্কে রয়েছে।

Comments

উত্তরের জন্য +1 আপনাকে ধন্যবাদ। এটি একটি খুব আকর্ষণীয় সমাধান এবং আমি বাশগুলির শ্রেণিবদ্ধ ক্রমের মাধ্যমে ব্রেস এবং ডান থেকে বাম পাঠ পছন্দ করি। (আমি এটি সঠিকভাবে বলেছি কিনা তা নিশ্চিত নয়)। আপনার উত্তরটি ইনপুট ফাইলের আকার এবং টাইমিং বেঞ্চমার্ক ফলাফলগুলির সাথে আপডেট করা সম্ভব যদি তা করা যথেষ্ট সহজ?

— WinEunuuchs2 ইউনিক্স

@ WinEunuuchs2 ইউনিক্স সময় যুক্ত করেছে, যদিও এটি খুব নির্ভরযোগ্য নয় কারণ এটি কোনও ভিএম-তে রয়েছে। এখনই আমার কাছে খালি-ধাতব উবুন্টু ইনস্টলেশনটি কার্যকর নেই।

— ডিজিটাল ট্রমা

আপনি যেভাবে যাইহোক ভিএম এর সাথে ভিএম তুলনা করছেন তা আমি মনে করি না ভিএম বনাম বেয়ার মেটালটি। সময় প্রমাণের জন্য ধন্যবাদ। আমি সম্ভবত সাথে যাব tailতবে এখনও মনে করি readবিকল্পটি খুব দুর্দান্ত।

— WinEunuuchs2 ইউনিক্স

Answer 3

আমার সিস্টেমে চেষ্টা করা এবং প্রতিটি কমান্ডের সাথে উপসর্গের সাথে timeনিম্নলিখিত ফলাফলগুলি পেয়েছি:

sed:

real    0m0.129s
user    0m0.012s
sys     0m0.000s

এবং লেজ:

real    0m0.003s
user    0m0.000s
sys     0m0.000s

যা বোঝায় যে আমার সিস্টেমে কমপক্ষে AMD FX 8250 উবুন্টু 16.04 চলছে, লেজটি উল্লেখযোগ্যভাবে দ্রুত। পরীক্ষার ফাইলে 540k আকারের 10,000 টি লাইন ছিল। ফাইলটি এইচডিডি থেকে পড়া হয়েছিল।

Comments

আপনাকে উত্তর দেওয়ার জন্য +1। এ.ই. চ্যাটরুমে পৃথক পরীক্ষায় একজন ব্যবহারকারী দেখিয়েছেন যে tail১ এমবি ফাইলের সাথে র‌্যামডিস্ক ব্যবহার করে লেজের চেয়ে শেড (২১..86 সেকেন্ড) এর চেয়ে দশগুণ দ্রুত (২.৩১ সেকেন্ড) হয় tail কোড ব্লক প্রয়োগ করতে আমি আপনার উত্তর সম্পাদনা করেছি তবে আপনি যে ফাইল ফাইলটি ব্যবহার করেছেন তা দিয়ে এটিও সম্পাদনা করতে চাইবেন want

— WinEunuuchs2 ইউনিক্স

@Serg একেবারে ন্যায্য এই শুধুমাত্র একটি অকল্পনীয় উত্তর হল, এবং সম্ভাব্য আপনি বিভিন্ন হার্ডওয়্যার কনফিগারেশনের সঙ্গে বিভিন্ন ফলাফল পেতে হবে, বিভিন্ন পরীক্ষা ফাইল ইত্যাদি

— নিক Sillito

ফাইল ক্যাশের মধ্যে হচ্ছে না, যখন ব্যবহার sedএই ফলাফলের একটা কারণ খেলা পারে, যাতে আপনি তাদের পরীক্ষা আছে আছে।

— Minix

কি ধরণের সিস্টেম? আমি এখানে অন্য পোস্টে যেমন মন্তব্য করেছি, আমার ম্যাকের sedদ্বিগুণ দ্রুত ছিল।

— কেভিন

Answer 4

কারণ এখন পর্যন্ত, যা উত্তম বলার কোন উদ্দেশ্য উপায় sedএবং tailশুধুমাত্র জিনিষ না যে প্রোগ্রাম সম্পাদনের সময় একটি সিস্টেম চলে। ডিস্ক আই / ও, নেটওয়ার্ক আই / ও, সিপিইউ উচ্চতর অগ্রাধিকার প্রসেসের জন্য বাধা দেয় - এর মতো অনেকগুলি কারণ আপনার প্রোগ্রামটি কত দ্রুত চালাবে তা প্রভাবিত করে।

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

কোন আদেশটি বেছে নেওয়ার কথা বিবেচনা করার সময় আপনি কয়েকটি বিষয় মনে রাখতে পারেন:

• তোমার উদ্দেশ্য কি ? sedপাঠ্য রূপান্তরের জন্য স্ট্রিম সম্পাদক। tailপাঠ্য নির্দিষ্ট লাইন আউটপুট জন্য। আপনি যদি লাইনগুলি নিয়ে ডিল করতে চান এবং কেবল সেগুলি মুদ্রণ করেন তবে ব্যবহার করুন tail। আপনি যদি পাঠ্যটি সম্পাদনা করতে চান তবে ব্যবহার করুন sed।
• tailএর চেয়ে অনেক বেশি সহজ বাক্য গঠন রয়েছে sed, তাই আপনি কী নিজে পড়তে পারেন এবং অন্যেরা কী পড়তে পারে তা ব্যবহার করুন।

---

আর একটি গুরুত্বপূর্ণ বিষয় হ'ল আপনি যে পরিমাণ ডেটা প্রক্রিয়া করছেন তা। ছোট ফাইলগুলি আপনাকে কোনও পারফরম্যান্সের পার্থক্য দেয় না। যখন আপনি বড় ফাইলগুলির সাথে ডিল করছেন তখন ছবিটি আকর্ষণীয় হয়ে ওঠে। ২ জিবি বিগফিল.টিএসটিএস্ট সহ আমরা দেখতে পাচ্ছি যে sedএর চেয়ে অনেক বেশি সিস্টেম কল রয়েছে tailএবং এটি যথেষ্ট ধীর গতিতে চলে।

bash-4.3$ du -sh BIGFILE.txt 
2.0G    BIGFILE.txt
bash-4.3$ strace -c  sed '1d' ./BIGFILE.txt  > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 59.38    0.079781           0    517051           read
 40.62    0.054570           0    517042           write
  0.00    0.000000           0        10         1 open
  0.00    0.000000           0        11           close
  0.00    0.000000           0        10           fstat
  0.00    0.000000           0        19           mmap
  0.00    0.000000           0        12           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         2           rt_sigaction
  0.00    0.000000           0         1           rt_sigprocmask
  0.00    0.000000           0         1         1 ioctl
  0.00    0.000000           0         7         7 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           getrlimit
  0.00    0.000000           0         2         2 statfs
  0.00    0.000000           0         1           arch_prctl
  0.00    0.000000           0         1           set_tid_address
  0.00    0.000000           0         1           set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00    0.134351               1034177        11 total
bash-4.3$ strace -c  tail  -n +2 ./BIGFILE.txt  > /dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 62.30    0.148821           0    517042           write
 37.70    0.090044           0    258525           read
  0.00    0.000000           0         9         3 open
  0.00    0.000000           0         8           close
  0.00    0.000000           0         7           fstat
  0.00    0.000000           0        10           mmap
  0.00    0.000000           0         4           mprotect
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0         3           brk
  0.00    0.000000           0         1         1 ioctl
  0.00    0.000000           0         3         3 access
  0.00    0.000000           0         1           execve
  0.00    0.000000           0         1           arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00    0.238865                775615         7 total

Comments

আপনাকে উত্তর দেওয়ার জন্য +1। তবে আমি নিশ্চিত নই যে এই মন্তব্যটি আমাকে কোন আদেশটি ব্যবহার করা উচিত তা সিদ্ধান্ত নিতে সহায়তা করছে ....

— WinEunuuchs2Unix

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

— সের্গি কলডায়াজহনি

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

— WinEunuuchs2 ইউনিক্স

@ WinEunuuchs2Unix নিশ্চিত, এখানে এটা: awk 'NR!=1' input_file.txt । এটা আমার সমানভাবে একই ফলাফল দেয়, প্রায় 150 মিলিসেকেন্ড, উভয়ের জন্য একই সংখ্যক tailএবং sed। তবে এজিিয়ান, আমি এসএসডি ব্যবহার করছি, তাই আমি এটি হার্ড ড্রাইভ এবং সিপিইউ যে গুরুত্বপূর্ণ তা নয়, বলব।

— সের্গেই কোলোডিয়াজনি

@ সার্জ এমনকি একটি 60 এমবি ফাইল সহ 1 এম লাইন রয়েছে, 1000 রান sed3 মিনিটের বেশি সময় নিয়ে যায়, যেখানে tailকেবল প্রায় 20 সেকেন্ডের প্রয়োজন। এটি আসলে এত বড় নয় , অবশ্যই জিবি পরিসরে নয়।

— বাইট কমান্ডার

Answer 5

শীর্ষের উত্তরটি ডিস্কটি অ্যাকাউন্টে নেয় নি > /dev/null

আপনার যদি একটি বড় ফাইল থাকে এবং আপনার ডিস্কে অস্থায়ী সদৃশ তৈরি করতে না চান তবে চেষ্টা করুন vim -c

$ cat /dev/urandom | base64 -w0 | tr 'n' '\n'| head -n 10000000 > testfile
$ time sed -i '1d' testfile

real    0m59.053s
user    0m9.625s
sys     0m48.952s

$ cat /dev/urandom | base64 -w0 | tr 'n' '\n'| head -n 10000000 > testfile
$ time vim -e -s testfile -c ':1d' -c ':wq'

real    0m8.259s
user    0m3.640s
sys     0m3.093s

সম্পাদনা করুন: যদি ফাইলটি মেমরির চেয়ে বড় হয় তবে মেমরিটি vim -cকাজ করে না, মনে হচ্ছে ফাইলটির বর্ধিত লোড করার মতো যথেষ্ট স্মার্ট নয়

Answer 6

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