জাভা কি আসলেই ধীর?


180

জাভা হয়েছে ধীর হওয়ার জন্য খ্যাতি কিছুটা

  • জাভা কি আসলেই ধীর?
  • যদি হ্যাঁ, কেন? (বা ছিল) বাধা কোথায়? এটি কি অকার্যকর জেভিএমগুলির কারণে? আবর্জনা সংগ্রহ? জেএনআই-মোড়ানো সি কোডের পরিবর্তে খাঁটি বাইটকোড লাইব্রেরি? অন্যান্য অনেক ভাষায় এই বৈশিষ্ট্যগুলি রয়েছে তবে স্বচ্ছতার জন্য তাদের এই খ্যাতি নেই।

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

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

3
ক্লায়েন্ট-সাইড ওয়েব দেব হিসাবে যিনি জাভাতে। নেট ওয়েবফর্ম,। নেট এমভিসি, পিএইচপি, রেলস, জ্যাঙ্গো এবং স্প্রিং (যা শুনেছি ভাল) এর বিস্তৃত বিভিন্ন বিষয় নিয়ে কাজ করেছেন, আমি খারাপ অভিনয় / আর্কিটেকচার আশা করি পিছনের দিক থেকে জাভা দলগুলি দ্বারা নির্মিত। আমি সন্দেহ করি যে আসল সমস্যাটি বেঞ্চমার্ক নয়, বরং সেখানে সাধারণ জাভা একটি বোকা টোন হওয়ার বিষয়টি আছে। এটি ভাষার দোষ নয়। এটি জাভা ডেভসদের দোষ নয় যারা প্রকৃতপক্ষে তাদের নৈপুণ্যকে জাল করে এবং জাভা ব্যতীত অন্য ভাষা শিখেন। তবে এটি সাধারণভাবে সান, শংসাপত্র, '90s এবং আইটি শিল্পের দোষ হতে পারে।
এরিক রেপেন

উত্তর:


236

মডার্ন জাভা দ্রুততম ভাষাগুলির মধ্যে একটি, যদিও এটি এখনও মেমরি হোগ। জাভা ধীর হওয়ার জন্য খ্যাতি ছিল কারণ এটি ভিএম শুরু করতে দীর্ঘ সময় নিয়েছিল।

তাহলে আপনি কি এখনও মনে জাভা ধীর দেখুন benchmarks খেলা ফলাফল নেই। শক্তিশালীভাবে অপ্টিমাইজড কোডগুলি একটি সামনের সময়ের সংকলিত ভাষায় লিখিত (সি, ফোর্টরান, ইত্যাদি) এটি বীট করতে পারে; তবে জাভা পিএইচপি, রুবি, পাইথন ইত্যাদির চেয়ে 10x-এর বেশি দ্রুততর হতে পারে There এমন নির্দিষ্ট ক্ষেত্র রয়েছে যেখানে এটি সাধারণ সংকলিত ভাষাগুলিকে পরাজিত করতে পারে (যদি তারা স্ট্যান্ডার্ড লাইব্রেরি ব্যবহার করে)।

"ধীর" জাভা অ্যাপ্লিকেশনগুলির জন্য এখন কোনও অজুহাত নেই। বিকাশকারী এবং লিগ্যাসি কোড / লাইব্রেরি ভাষার থেকে অনেক বেশি দোষারোপ করে। এছাড়াও, 'এন্টারপ্রাইজ' যেকোন কিছুতে দোষ দিন।

"জাভা ধীর" ভিড়ের প্রতি ন্যায়বিচারের জন্য, এখানে এমন অঞ্চলগুলি রয়েছে যেখানে এটি এখনও ধীর (2013 সালের জন্য আপডেট করা):

  • গ্রন্থাগারগুলি প্রায়শই "নির্ভুলতা" এবং পাঠযোগ্যতার জন্য রচনা করা হয়, পারফরম্যান্সের জন্য নয়। আমার মতে জাভাটির এখনও বিশেষভাবে সার্ভার-সাইডের খারাপ খ্যাতি রয়েছে এটিই মূল কারণ। এটি স্ট্রিং সমস্যাগুলি তাত্পর্যপূর্ণভাবে আরও খারাপ করে তোলে। কিছু সাধারণ ভুল সাধারণ: বস্তুগুলি প্রায়শই আদিমের জায়গায় ব্যবহার করা হয়, কর্মক্ষমতা হ্রাস করে মেমরির ব্যবহার বৃদ্ধি করে। অনেক জাভা লাইব্রেরি (মানকগুলি সহ) স্ট্রিংগুলি ঘন ঘন তৈরি করবে, পরিবর্তে পরিবর্তনযোগ্য বা সহজ ফর্ম্যাটগুলি (চর [] বা স্ট্রিংবফার) পুনরায় ব্যবহার না করে। এটি ধীরে ধীরে এবং পরে সংগ্রহ করার জন্য প্রচুর পরিমাণে আবর্জনা তৈরি করে। এটি ঠিক করার জন্য, আমি বিকাশকারীগণ আদিম সংগ্রহগুলি এবং বিশেষত জাভালিউশনের লাইব্রেরিগুলি যেখানে সম্ভব সেখানে ব্যবহার করার পরামর্শ দিচ্ছি।

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

  • সি এর তুলনায় অ্যারে অ্যাক্সেস কিছুটা ধীর,বাউন্ড চেকের কারণে । পেনাল্টিটি বড় হিসাবে ব্যবহৃত হত, তবে এখন এটি সামান্য (জাভা 7 অনেকগুলি রিন্ডন্ড্যান্ট বাউন্ডস চেক অপ্টিমাইজ করে)।

  • স্বেচ্ছাসেবী মেমরি অ্যাক্সেসের অভাবের ফলে কিছু I / O এবং বিট-লেভেল প্রসেসিং ধীর হয়ে যায় (উদাহরণস্বরূপ সংক্ষেপণ / সংক্ষেপন)। এটি এখন বেশিরভাগ উচ্চ-স্তরের ভাষার একটি সুরক্ষা বৈশিষ্ট্য।

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

  • স্ট্রিম-ভিত্তিক আই / ও প্রতিটি স্ট্রিম অ্যাক্সেসে সিঙ্ক্রোনাইজেশন প্রয়োজন (আইএমও, দুর্বল পছন্দ) এর কারণে ধীরএনআইও এটি ঠিক করেছে তবে এটি ব্যবহারে ব্যথা। একবারে কোনও উপাদানের পরিবর্তে অ্যারেতে / পড়ার মাধ্যমে কেউ এটিকে ঘিরে কাজ করতে পারেন।

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

  • জাভা অ্যাপ্লিকেশনগুলি খুব পুরানো জেভিএম সংস্করণে আবদ্ধ হওয়া দেখতে সাধারণ। বিশেষত সার্ভার-সাইড এই পুরানো জেভিএম সর্বশেষ সংস্করণগুলির সাথে তুলনায় অবিশ্বাস্যভাবে অদক্ষ হতে পারে।

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


তবে, বেশ কয়েকটি জায়গা যেখানে জাভা অন্যান্য ভাষার চেয়ে দ্রুততর হয় :

  • মেমরি বরাদ্দ এবং ডি-বরাদ্দ দ্রুত এবং সস্তা। আমি এমন কেসগুলি দেখেছি যেখানে ক্যাশেডটিকে পুনরায় ব্যবহার করার চেয়ে নতুন, মাল্টি-কেবি অ্যারের বরাদ্দ করা 20% দ্রুত (বা আরও বেশি)!

  • অবজেক্ট ইনস্ট্যান্টেশন এবং অবজেক্ট-ওরিয়েন্টেড বৈশিষ্ট্যগুলি দ্রুত ব্যবহার করার জন্য জ্বলজ্বল করছে (কিছু ক্ষেত্রে সি ++ এর চেয়ে দ্রুত), কারণ সেগুলি প্রথম থেকেই ডিজাইন করা হয়েছে। এটি আংশিকভাবে সুস্পষ্ট বরাদ্দের চেয়ে ভাল জিসি থেকে এসেছে (যা প্রচুর ছোট বস্তুর বরাদ্দের চেয়ে বেশি বন্ধুত্বপূর্ণ)। যে কোনও এটি সিটিকে কোড করতে পারে (কাস্টম মেমরি পরিচালনা রোল করে এবং দক্ষতার সাথে ম্যালোক করে) তবে এটি সহজ নয়।

  • পদ্ধতি কলগুলি মূলত বিনামূল্যে এবং কিছু ক্ষেত্রে বৃহত-পদ্ধতি কোডের চেয়ে দ্রুত। হটস্পট কম্পাইলার অপ্টিমাইজ পদ্ধতি কল সঞ্চালনের তথ্য ব্যবহার করে এবং খুব দক্ষ ইনলাইনিং হয়েছে। অতিরিক্ত নির্বাহের তথ্য ব্যবহার করে, এটি কখনও কখনও সময়ের পূর্বেকার এবং এমনকি (বিরল ক্ষেত্রে) ম্যানুয়াল ইনলাইনিংকে ছাড়িয়ে যায়। সি / সি ++ এর সাথে তুলনা করুন যেখানে কম্পাইলার ইনলাইন না করার সিদ্ধান্ত নিয়ে যদি পদ্ধতি কলগুলি একটি ছোট পারফরম্যান্স জরিমানা নিয়ে আসে।

  • সিঙ্ক্রোনাইজেশন এবং মাল্টি-থ্রেডিং সহজ এবং দক্ষ। জাভা শুরু থেকেই থ্রেড-সচেতন হওয়ার জন্য ডিজাইন করা হয়েছিল এবং এটি দেখায়। আধুনিক কম্পিউটারগুলিতে সাধারণত একাধিক কোরের বৈশিষ্ট্য রয়েছে এবং থ্রেডিংটি ভাষায় অন্তর্নির্মিত হওয়ায় আপনি খুব সহজেই সুবিধা নিতে পারেন। মূলত একটি অতিরিক্ত 100% থেকে 300% গতি বৃদ্ধি বনাম মান, একক থ্রেডেড সি কোড। হ্যাঁ, সাবধানে লিখিত সি থ্রেডিং এবং লাইব্রেরিগুলি এটি হারাতে পারে তবে প্রোগ্রামারটির জন্য এটি অনেক অতিরিক্ত কাজ।

  • স্ট্রিংগুলির দৈর্ঘ্য অন্তর্ভুক্ত থাকে: কিছু অপারেশন দ্রুত হয়। নাল-সীমাবদ্ধ স্ট্রিংগুলি (সি তে সাধারণ) ব্যবহার করে এই মারধর করে। জাভা 7-এ, ওরাকল স্ট্রিং.সুবস্ট্রিং () অপ্টিমাইজেশানটি গ্রহণ করেছে, কারণ লোকেরা এটি বোকামিভাবে ব্যবহার করছে এবং মেমরি ফাঁস পাচ্ছে।

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

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

"জাভা ইজ স্লো" খ্যাতিতে কয়েকটি historicalতিহাসিক তথ্য অবদান রেখেছিল:

  • জেআইটি সংকলনের আগে (জাভা ১.২ / ১.৩) ভাষার কেবল ব্যাখ্যা করা হয়েছিল, সংকলন করা হয়নি এবং এভাবে খুব ধীর গতিতে ছিল।
  • জেআইটি সংকলনটি দক্ষ হওয়ার জন্য সময় নিয়েছে (প্রতিটি সংস্করণের সাথে বড় উন্নতি)
  • ক্লাসলোডিং কয়েক বছর ধরে অনেক বেশি দক্ষ হয়ে উঠেছে। এটি স্টার্টআপের সময় বেশ অদক্ষ এবং ধীর হয়ে যেত।
  • সুইং এবং ইউআই কোড নেটিভ গ্রাফিক্স হার্ডওয়্যার খুব ভাল ব্যবহার করে না।
  • দোল শুধু ভয়ঙ্কর। আমি জাভা কেন ডেস্কটপের জন্য কখনই ধরতে পারি নি তার জন্য আমি এডাব্লুটি এবং সুইংকে দায়ী করি।
  • লাইব্রেরি ক্লাসে সুসংগতকরণের ভারী ব্যবহার; অপরিবর্তিত সংস্করণগুলি এখন উপলভ্য
  • নেটওয়ার্কের মাধ্যমে একটি পূর্ণ জেআর স্থানান্তরিত করে এবং ভিএম বুটে লোড করার কারণে অ্যাপলেটগুলি চিরতরে লোড হতে পারে।
  • ভারী পারফরম্যান্স পেনাল্টি বহন করতে ব্যবহৃত সিঙ্ক্রোনাইজেশন (এটি প্রতিটি জাভা সংস্করণের সাথে অনুকূলিত করা হয়েছে)। প্রতিচ্ছবি এখনও ব্যয়বহুল, যদিও।

49
Object instantiation and object-oriented features are blazing fast to use (faster than C++ in many cases) because they're designed in from the beginning.এবং Collections are fast. Standard Java beats standard C/C++ in this area, even for most optimized C code.এখানে লিঙ্কযুক্ত কোনও প্রমাণ দ্বারা বন্য দাবিগুলি অসমর্থিত।
সোজয়ের্ড

8
@ সোজার্ড - দাবিগুলি খুব কমই বন্য - এটি আমার কাছে সুস্পষ্ট, এবং সি / সি ++ বনাম জাভাতে ডিফল্ট মেমরি সিস্টেমের আর্কিটেকচারের পার্থক্য বুঝতে পারে এমন কাউকেই হওয়া উচিত। আপনি নিজের মেমরি হ্যান্ডলারগুলি (ফ্রি তালিকা, মেমরি পুলের মতো জিনিস সহ) লিখে বা এমন একটি লাইব্রেরি ব্যবহার করেন যা এখনও কার্যকর করতে পারেন আপনি আরও বেশি কিছু করতে পারেন।
রেক্স কের

15
@ রেক্স কের - যদি আপনি যেমন বরাদ্দের জন্য স্ট্যাক ব্যবহার করতে পারেন তবে মেমরি হ্যান্ডলারগুলি কেন ব্যবহার করবেন ?! আপনি অবজেক্ট ইনস্ট্যান্টেশন দিয়ে হিপ মেমরির বরাদ্দকে বিভ্রান্ত করছেন।
সুজার্ড

20
@ রেক্স কের - মূলত আপনি দাবী করছেন যে যেহেতু জাভাতে সমস্ত কিছু গাদাতে মেমরি বরাদ্দ করা জড়িত, এবং যেহেতু জাভাতে স্তূপে জাভা বরাদ্দ রয়েছে তা সি ++ এর চেয়ে দ্রুত, জাভার সমস্ত কিছুই দ্রুত। আপনার জন্য এখানে কিছু খবর: সি ++ এ আপনি অনেক ক্ষেত্রে গাদাতে মেমরি বরাদ্দ না করে করতে পারেন!
Sjoerd

10
@Sjoerd - আমি কোথায় বললে যে সবকিছু জাভা দ্রুত সারাবে কে? আমি যা বলেছি তা কেবল পড়ুন। আমি যা বলতে চাইছিলাম তা বলেছি এবং আপনি আপনার শেষ মন্তব্যে যা বলেছেন তা ইতিমধ্যে সম্বোধন করেছেন।
রেক্স কের

49

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

  1. স্লো ভিএম স্টার্টআপ সময়। আদি জাভা প্রয়োগের দেশীয় অ্যাপ্লিকেশনগুলির তুলনায় প্রয়োজনীয় লাইব্রেরি এবং অ্যাপ্লিকেশন শুরু এবং লোড করতে দীর্ঘ সময় নিয়েছিল।

  2. ধীর UI। প্রারম্ভিক সুইং ছিল ধীর। এটি সম্ভবত সহায়ক হয়নি যে বেশিরভাগ উইন্ডোজ ব্যবহারকারীরা ডিফল্ট ধাতব এলএন্ডএফটিকে কুরুচিপূর্ণভাবে খুঁজে পেয়েছিল।

উপরোক্ত বিষয়গুলি প্রদত্ত, এতে অবাক হওয়ার কিছু নেই যে লোকেরা 'জাভা ইজ স্লো' ছাপ পেয়েছে।

ব্যবহারকারী বা বিকাশকারীদের জন্য স্থানীয় অ্যাপ্লিকেশন, এমনকি ভিজ্যুয়াল বেসিক বিকাশ করতে অভ্যস্ত অ্যাপ্লিকেশন , তাদের জন্য এই দুটি পয়েন্ট একটি অ্যাপ্লিকেশনের মধ্যে সর্বাধিক দৃশ্যমান জিনিস এবং এটি কোনও অ্যাপ্লিকেশন সম্পর্কে আপনি প্রথম ধারণা পাবেন (এটি যদি কোনও নন-জিইউআই অ্যাপ্লিকেশন থাকে তবে কেস শুধুমাত্র 1. প্রয়োগ।)।

আপনি কোনও ব্যবহারকারীকে বোঝাতে পারবেন না যে "অ্যাপ্লিকেশনটি খুব দ্রুত কোড কার্যকর করে" যখন বনামটি শুরু করতে 8 সেকেন্ড সময় লাগে তার তাত্ক্ষণিকভাবে শুরু হওয়া তার পুরানো ভিজ্যুয়াল বেসিক অ্যাপ্লিকেশনটি - যদিও কোড এক্সিকিউশন এবং প্রারম্ভকালীন সময় মোটেই সংযুক্ত না থাকে।

গুজব এবং পৌরাণিক কাহিনী শুরু করার জন্য প্রথম ছাপটি নষ্ট করা একটি দুর্দান্ত উপায়। গুজব এবং কল্পকাহিনী হত্যা করা কঠিন।

সংক্ষেপে, জাভা ধীর হয় না। 10 বছরেরও বেশি আগে জাভা প্রথম ইমপ্রেশনগুলির উপর ভিত্তি করে "জাভা হ'ল ধীর দৃষ্টিভঙ্গি" রয়েছে People


3
কয়েক বছর আগে জাভা খুব ধীর ছিল তবে সাম্প্রতিক বেঞ্চমার্ক পরীক্ষায় এটি সি / সি ++ এর মতো প্রায় দ্রুত চলে এবং কিছু পরিস্থিতিতে এটি দ্রুত গতিতে চলে।
চাদএনসি

23
আমার ম্যাকবুকের ওএসএক্স 10.6 এ থাকা জাভা অ্যাপ্লিকেশনগুলি উদ্দেশ্য-সি-তে লিখিত অ্যাপ্লিকেশনগুলির চেয়ে অনেক ধীরে শুরু হয়। দ্রুত প্রারম্ভকালীন সময় জন্য কি প্রমাণ?
জ্যান লিংস

2
ডিকম্প্রেশন একেবারে পারফরম্যান্সের সমস্যা নয়। 1992 সালে আমার কম্পিউটার প্রোগ্রামগুলি শুরু করার সময় এক্সিকিউটেবলকে সঙ্কুচিত করেছিল যা হার্ড ড্রাইভ থেকে দীর্ঘতর ফাইল লোড করার ক্ষেত্রে পারফরম্যান্সের উন্নতি করে। মধ্যবর্তী বছরগুলিতে সিপিইউ এবং হার্ড ড্রাইভের মধ্যে বৈষম্য প্রচুর পরিমাণে বেড়েছে। তবে, rt.jar (কেন? !!!) এর জন্য জিপ সংরক্ষণাগার বিন্যাসটি ব্যবহার করতে সমস্যা রয়েছে এবং এতে থাকা শ্রেণি ফাইলগুলি লিঙ্কযুক্ত নয় (বাদাম !!)।
টম হাটিন -

5
@ জ্যান: নোট করুন যে ম্যাক ওএস এক্স এর জন্য জেভিএম অ্যাপল লিখেছেন (বা কমপক্ষে অভিযোজিত)। তারা যে প্ল্যাটফর্মগুলি সমর্থন করে (উইন্ডোজ, লিনাক্স এবং সোলারিস) শুরু করার সময় দ্রুত করার জন্য সান বেশ কিছুটা সময় ব্যয় করেছে, তবে তারা ম্যাক ওএস এক্সের জন্য এটি করতে পারেনি (যেহেতু তারা এই বন্দরটি বজায় রাখেন না)। এটি ম্যাক ওএস এক্স-তে সমস্ত অপ্টিমাইজেশন ম্যাক / প্রয়োগ / পোর্ট করতে পারেনি
জোচিম সৌর

1
আমি জাভাটিকে ধীর বলে বিবেচনা করি না (আমি এমন একটি গেম প্রস্তুতকারীকে জানি যা তাদের মধ্যে গেম তৈরি করে); ইউআই কারণে খারাপ। আমি দেখেছি এমন একটিও "নিয়মিত" জাভা অ্যাপ্লিকেশনটিতে একটি শালীন, সম্পূর্ণরূপে কাজ করা UI নেই।
আরসিআইএক্স

40

জাভা ধীর নয় বলে মন্তব্য করে পূর্ণ একটি পৃষ্ঠা পড়ার পরে, আমাকে কেবল একটি পৃথক মতামত দিয়ে উত্তর দিতে হবে।

কোনও ভাষার অস্তিত্ব আপনার 'দ্রুত' এর জন্য কী প্রত্যাশা তা নির্ভর করে। আপনি যদি সি # কে দ্রুত বলে বিবেচনা করেন তবে অবশ্যই জাভা খুব দ্রুত। আপনার সমস্যা ডোমেন যদি ডেটাবেস বা অর্ধ রিয়েল-টাইম প্রসেসিংয়ের সাথে সম্পর্কিত হয় তবে জাভা অবশ্যই খুব দ্রুত is আপনি যদি আরও হার্ডওয়্যার যুক্ত করে আপনার অ্যাপ্লিকেশনটি স্কেল করতে খুশি হন তবে জাভা সম্ভবত আপনার পক্ষে দ্রুত। যদি আপনি বিবেচনা করেন যে 5-10 স্কেলের একটি ধ্রুবক ফ্যাক্টর গতিপথ এটির পক্ষে ভাল নয় তবে আপনি সম্ভবত জাভাটিকে দ্রুত বিবেচনা করবেন।

আপনি যদি বড় ডেটা সেটগুলিতে সংখ্যার গণনা করেন, বা এক্সিকিউশন পরিবেশে আবদ্ধ হন, যেখানে সিপিইউ সংস্থানগুলি সীমিত, যেখানে 5-10 স্কেলের একটি ধ্রুবক গতিপথ বিশাল হবে up এমনকি একটি 0.5 গতিবেগের অর্থ গণনাটি সম্পূর্ণ হতে 500 ঘন্টা হ্রাস হতে পারে। এই ক্ষেত্রে, জাভা আপনাকে পারফরম্যান্সের শেষ গজটি পেতে দেয় না এবং আপনি সম্ভবত জাভাটিকে ধীর বলে বিবেচনা করবেন।


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

33

আপনি দুটি ভিন্ন প্রশ্ন জিজ্ঞাসা করছেন বলে মনে হচ্ছে:

  1. জাভা কি আসলেই ধীর, আর যদি তাই হয় কেন?
  2. অনেক বিকল্পের চেয়ে দ্রুততর হওয়া সত্ত্বেও কেন জাভাটিকে ধীর বলে মনে করা হচ্ছে?

এর মধ্যে প্রথমটি কমবেশি একটি "দড়িটি কত দিন" ধরণের প্রশ্ন। এটি আপনার "ধীর" সংজ্ঞায় নেমে আসে। খাঁটি দোভাষীর তুলনায় জাভা অত্যন্ত দ্রুত। অন্যান্য ভাষাগুলির সাথে তুলনা করা (যা সাধারণত) কোনও ধরণের বাইটোকডের সাথে সংকলিত হয়, তারপরে গতিশীলভাবে মেশিন কোডে সংকলিত হয় (যেমন সি # বা .NET- এ অন্য যে কোনও কিছু) জাভা মোটামুটি পার্শ্বে থাকে। সাধারণত খাঁটি মেশিন কোডে সংকলিত ভাষাগুলির সাথে তুলনা করা হয় এবং তাদের অপটিমাইজারগুলি উন্নত করা (যেমন সি, সি ++, ফোর্টরান, অ্যাডা) ছাড়া কিছুতেই কাজ করা লোকের দল (প্রায়শই বড়) রয়েছে জাভা কয়েকটি জিনিস নিয়ে বেশ ভাল করেছে তবে সামগ্রিকভাবে অন্তত কিছুটা ধীর হতে থাকে।

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

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

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

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

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

এগুলি একসাথে যুক্ত করা মোটামুটি সহজ এবং প্রাকৃতিক প্রতিক্রিয়ার দিকে নিয়ে যায়: যে জাভা ধীর, কুৎসিত এবং আনাড়ি। হাইপটি বলেছিলেন যে এটি সত্যিই দ্রুত, একটি (আরও নির্ভুল) "পরিবর্তে কিছুটা ধীরগতির পরিবর্তে, এবং এটি বেশিরভাগ নির্দিষ্ট পরিস্থিতিতে" খুব বেশি ধীরে ধীরে ধীরে ধীরে ওভারট্যাক্ট করার এবং এটিকে ভয়াবহরূপে ভাবার প্রবণতা রয়েছে " কোনও বিকাশকারী ভাষায় প্রথম কয়েকটি প্রোগ্রাম লেখার ক্ষেত্রে এটি সাধারণত সবচেয়ে খারাপ হয়। বেশিরভাগ ভাষায় একটি "হ্যালো ওয়ার্ল্ড" প্রোগ্রামের প্রয়োগ তাত্ক্ষণিকভাবে উপস্থিত হয়, তবে জাভিতে জেভিএম শুরু হওয়ার সাথে সাথে একটি সহজেই উপলব্ধিযোগ্য বিরতি দেখা যায়। এমনকি খাঁটি দোভাষী যে টাইট লুপগুলিতে আরও ধীরে ধীরে চলতে থাকে এবং এ জাতীয় কোডের জন্য এখনও প্রায়শই দ্রুত উপস্থিত হবে, কেবল কারণ এটি লোড হয়ে যায় এবং কিছুটা শীঘ্রই কার্যকর করা শুরু করে।


16

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

অন্যান্য অনেক জনপ্রিয় আধুনিক ভাষার তুলনায় (পাইথন, রুবি, পিএইচপি), জাভা বেশিরভাগ ব্যবহারের জন্য আসলে উল্লেখযোগ্যভাবে দ্রুত faster এটি সি বা সি ++ এর সাথে পুরোপুরি মেলে না তবে অনেক কাজের জন্য এটি যথেষ্ট কাছে। আসল পারফরম্যান্স উদ্বেগগুলি এটি হওয়া উচিত যে এটি কত স্মৃতি ব্যবহার করে শেষ হয়।


14

"দীর্ঘ প্রারম্ভকালীন সময়" এর মূল অপরাধী হ'ল গতিশীল সংযোগ। একটি জাভা অ্যাপ্লিকেশন সংকলিত ক্লাস নিয়ে গঠিত। প্রতিটি বর্গ রেফারেন্স অন্য ক্লাসের দ্বারা (আর্গুমেন্ট প্রকার, পদ্ধতি আমন্ত্রণ ... জন্য) নাম । জেভিএম অবশ্যই প্রারম্ভের পরে অবশ্যই এই নামগুলি পরীক্ষা করে দেখা উচিত match এটি এতগুলি বর্ধনশীলভাবে করে, যে কোনও অংশের প্রয়োজন হয় কেবলমাত্র সেই অংশগুলিতে, তবে এটি এখনও কিছু কাজ বাকি।

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

জাভাতে, অ্যাপ্লিকেশনটি চালিত হওয়ার সাথে সাথে লিঙ্কিং ঘটে। অতএব দীর্ঘ প্রারম্ভ সময়।

ক্যাচিং কৌশল সহ বিভিন্ন অপ্টিমাইজেশন প্রয়োগ করা হয়েছে, এবং কম্পিউটারগুলি দ্রুততর হয় (এবং অ্যাপ্লিকেশনগুলি "আরও বড়" পাওয়ার চেয়ে তারা "আরও দ্রুত" পায়), সুতরাং সমস্যার গুরুত্ব ইদানীং অনেক হ্রাস পেয়েছে; তবে পুরাতন কুসংস্কার রয়ে গেছে।

পারফরম্যান্স পরবর্তী হিসাবে, অ্যারে অ্যাক্সেসগুলি (বেশিরভাগ হ্যাশ ফাংশন এবং অন্যান্য ক্রিপ্টোগ্রাফিক অ্যালগরিদম) সহ কমপ্যাক্ট কম্পিউটারে আমার নিজস্ব মানদণ্ডগুলি সাধারণত দেখায় যে অনুকূলিত সি কোড জাভা কোডের চেয়ে প্রায় 3x গতিযুক্ত; কখনও কখনও সি জাভা থেকে 30% দ্রুত, কখনও কখনও সি প্রয়োগ করা অ্যালগরিদমের উপর নির্ভর করে 4x দ্রুত হতে পারে। আমি 10x ফ্যাক্টরটি দেখেছি যখন "সি" কোডটি প্রকৃতপক্ষে বড় পূর্ণসংখ্যার গাণিতিকদের জন্য সমাবেশ ছিল, 64x64-> 128 গুণিত ওপকোডের কারণে যা প্রসেসরের অফার করে তবে জাভা ব্যবহার করতে পারে না কারণ এর দীর্ঘতম পূর্ণসংখ্যার প্রকারটি 64-বিট long। এটি একটি প্রান্তের কেস। ব্যবহারিক অবস্থার অধীনে I / O এবং মেমরি ব্যান্ডউইডথ বিবেচনার হওয়া থেকে সি কোড প্রতিরোধ সত্যিই তিনবার জাভা তুলনায় দ্রুততর।


হুম ... আমি ভেবেছিলাম বেশিরভাগ সি লাইব্রেরিগুলি আজকালও গতিশীলভাবে সংযুক্ত ছিল। নাকি অন্যরকম কিছু বলছেন?
শন ম্যাকমিলান

4
@ শিয়ান: সি এর সাথে গতিশীল সংযোগ ঘটে "বাহ্যিক প্রতীক": যে ফাংশনগুলি একটি ডিএলএলে ব্যবহৃত হয় এবং অন্যটিতে সংজ্ঞায়িত হয়। একটি সাধারণ সি অ্যাপ্লিকেশনটিতে এক ডজন ডিএলএল ব্যবহার করা হবে। জাভা জন্য গতিশীল লিঙ্কিং সমস্ত শ্রেণীর সমস্ত পদ্ধতির জন্য ঘটে: একটি আদর্শ জাভা অ্যাপ্লিকেশনটিতে ( হাজার হাজার স্ট্যান্ডার্ড লাইব্রেরি সহ) হাজার হাজার রয়েছে। সি বিশ্বে, বেশিরভাগ লিঙ্কিং (সমস্ত লিঙ্কগুলি যা একটি ডিএলএল সীমানা অতিক্রম করে না) সংকলনের সময়ে সমাধান করা হয়, রানটাইমে কেবলমাত্র একটি সামান্য অনুপাত এখনও বাকী রয়েছে।
টমাস পর্নিন

14

জাভা স্পষ্টত ধীরে ধীরে, বিশেষত পরিমাণগত কাজের জন্য।

আমি অপ্টিমাইজড মাল্টিথ্রেডেড আটলাস লাইব্রেরির সাথে আর , পাইথন এবং সি / সি ++ এর সংমিশ্রণটি ব্যবহার করি । এই প্রতিটি ভাষাতে আমি ম্যাট্রিক্সকে প্রায় 4 সেকেন্ডের মধ্যে নিজের সাথে 3000 দ্বারা 3000 ম্যাট্রিক্স ডাবলসকে গুণতে পারি। জাভাতে কোল্ট এবং সমান্তরাল কোল্ট ব্যবহার করে, একই ক্রিয়াকলাপটি 185 সেকেন্ডে লাগে! এই জাভা গ্রন্থাগারগুলি প্রকৃতির সমান্তরাল হওয়া সত্ত্বেও অবাক করা।

সব মিলিয়ে খাঁটি জাভা পরিমাণগত কাজের জন্য অনুপযুক্ত। জাব্লাস এটি জাফল্যের জন্য সেরা লিনিয়ার বীজগণিত গ্রন্থাগার হিসাবে মনে হচ্ছে এটি আটলাস ব্যবহার করে।

আমার মেশিনটি 3 গিগাবাইট র‌্যাম সহ একটি এইচপি কোর 2 জুটি । আমি 64-বিট উবুন্টু 10.04 (লুসিড লিংক) ব্যবহার করি।


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

7
আপনি জেএনআই এর মাধ্যমে কল করা লাইব্রেরিগুলিতে গুণটি সম্পাদন করার সময় জাভা কতক্ষণ সময় নিয়েছিল। আপনি সিএন / সি ++ এ যা কিছু করতে পারেন তা দিয়ে আপনি জেএনআইয়ের সাথে কিছু করতে পারেন (কয়েকশত ম্যানানো-সেকেন্ড যুক্ত করুন) মার্জিনটি তুলনামূলকভাবে কম। আমি অনুমান করছি যে আপনার আর এবং পাইথন ম্যাট্রিক্সের গুণটি আর বা পাইথনে লেখা হয়নি, কেবল সেই ভাষা থেকে ডাকা হয়েছে।
পিটার লরে

2
কৌতূহলের বাইরে, আপনার কোডে কিছু হটস্পট রয়েছে কিনা তা সনাক্ত করার জন্য আপনি কোনও প্রোফাইলিং করেছেন (ধরণের রূপান্তর / অটোবক্সিং)?
থরবজর্ন রাভন অ্যান্ডারসন

10

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

এটি ধীরে ধীরে JVM স্পিন আপ এবং অ্যাপলেট ডাউনলোডের সময়টিকে জাভা কফি কাপের সাথে স্পষ্টতই ব্র্যান্ডেড করা সাহায্য করে না, তাই লোকেরা জাভাটির সাথে অপেক্ষাটি যুক্ত করে। যখন ফ্ল্যাশ লোড একটি দীর্ঘ সময় লাগে, "লোড" বার্তা ব্র্যান্ডিং ফ্ল্যাশ ডেভেলপার দ্বারা নির্দিষ্ট করা হয় যাতে মানুষ সামগ্রিকভাবে ফ্ল্যাশ প্রযুক্তি দোষারোপ করবেন না।

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


9

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

আপনি যদি দেখতে চান যে জেআইটি সংকলনটি কতটা বড় পার্থক্য তৈরি করে, কম্পিউটার ল্যাঙ্গুয়েজ বেঞ্চমার্ক গেমের ব্যাখ্যায়িত বনাম অ-ব্যাখ্যা করা বেঞ্চমার্কগুলি পরীক্ষা করে দেখুন । (পিডিজিটস সমস্ত গণনা করার জন্য একটি বাহ্যিক গ্রন্থাগার ব্যবহার করে, যাতে মাপদণ্ডের পরিবর্তন হয় না; অন্যরা 6-16x স্পিডআপ দেখায়!)

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


6

জাভা ডাব্লু ধীর ছিল, দিনের মধ্যে ফিরে। পারফরম্যান্স বর্ধনের কয়েক প্রজন্মের কারণে এটি অনেক দ্রুত হয়ে উঠেছে । শেষ আমি শুনেছি, এটি সাধারণত সি # গতির 10% এর মধ্যে থাকে - কখনও কখনও দ্রুত, কখনও কখনও ধীর হয়।

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

এছাড়াও, কমপক্ষে কয়েক জন লোক রয়েছেন যা কখনই জাভাটির কার্যক্ষমতায় বিশ্বাস করবেন না।


1
দুর্ভাগ্যক্রমে, জেভিএম স্টার্টআপটি সিএলআর স্টার্টআপের তুলনায় এখনও অনেক ধীর। এটি কারণ জাভা 7 প্রকাশের ক্ষেত্রে সান সবচেয়ে খারাপভাবে তার পা টেনে নিয়েছে, সুতরাং আমরা 4 বছরের পুরানো জাভা 6
বর্ধমান

3
বাহ, জাভা 6 এর বয়স 4 বছর ??? হ্যাঁ আমি অনুমান করি (আপনি যদি বিটা গণনা করেন)। তবুও আমার কাছে নতুন অনুভূত হয় - আমি কাজের জায়গায় ১.৪ ব্যবহার করা বন্ধ করে দিয়েছি
কালেব ব্রসি

জাভা ১.৪ ব্যবহারযোগ্য, তবে এক ধরণের sucktastic, যেহেতু 1.5 এবং 1.6 প্রচুর কর্মক্ষমতা বৃদ্ধি করে এবং সিনট্যাকটিক চিনির যোগ করে। তখন থেকে বাউন্ডস-চেক এবং সিস্টেম.আররেইকপি অপ্টিমাইজেশানগুলি চালু হয়েছিল। তাই সিঙ্ক্রোনাইজেশনের অনেক উন্নতি হয়েছিল। আমি মনে করি এটি যথাযথভাবে 1.4 বলার অপেক্ষা রাখে না IS
ববএমসিজি

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

6

স্টেফানো:

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

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

ব্যাকএন্ডে এবং গণনার স্তরে জাভা এত ধীর নয়। অশ্বশাবক অন্যতম সেরা উদাহরণ:

সর্বশেষতম স্থিতিশীল কোল্ট রিলিজ জেডি কে আইবিএম-১.৪.১, রেডহ্যাট ৯.০, ২ এক্স ইনটেল্যাক্সন @ ২.৮ গিগাহার্জ-তে 1.9 জিএফলপ / এস বাধা ভেঙেছে।

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

আমি মনে করি যে সাধারণত আজ এটি একটি রাজনৈতিক সিদ্ধান্ত (যেমন আইফোন / আইপডে জাভা সমর্থন নয়), এবং জাভার বিরুদ্ধে ভাষা হিসাবে সিদ্ধান্ত (কারণ অনেকে মনে করেন এটি খুব ভার্জোজ)।

তবে আজকাল জাভা ভিএম এর জন্য আরও অনেক ভাষা রয়েছে (যেমন পাইথন, রুবি, জাভাস্ক্রিপ্ট, গ্রোভি, স্কালা ইত্যাদি) যা বিকল্প হতে পারে।

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


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

স্টেফানো: সুইং আসলে উইজেটগুলির অ-নেটিভ সর্বজনীন রেন্ডারিংয়ের ধারণার ভিত্তিতে তৈরি তাই আপনার অনুমানটি একধরণের ভুল। এটি প্রকৃতপক্ষে একটি "প্লাগযোগ্য রূপ এবং অনুভূতি" প্রক্রিয়া যা সুইং উপাদানগুলিকে দেশীয় উপাদানগুলির উপস্থিতি অনুকরণ করতে দেয়। আপনি যদি এর মতো কিছু সন্ধান করে থাকেন তবে আপনি SWT ( eclipse.org/swt ) যাচাই করতে চাইতে পারেন , যা প্রকৃতপক্ষে নেটিভ ওএসে প্রবেশ করবে এবং জেএনআই (যা বলা হয় যে এটি একটি বাধা) হিসাবে ব্যবহার করে নেটিভ উইজেট ব্যবহার করবে।
ডায়েটার

জাভা 2 ডি (সুইংয়ের জন্য ব্যবহৃত) এই দিনগুলিতে খুব দ্রুত, এবং নেটিভ উইজেটগুলি (এসডাব্লুটি) ব্যবহার করা কোনও কার্যকারিতা সুবিধা দেয় না। কমপক্ষে, আমি 6 মাস আগে সুইং বা এসডাব্লুটি শিখব কিনা তা সিদ্ধান্ত নেওয়ার সময় আমি এটি পড়েছিলাম।
লুইজি প্লিঞ্জ

4

একটি হাতুড়ি অন্যান্য অনেক সরঞ্জামের তুলনায় ময়দা ঘুরিয়ে তুলতে খুব ধীর হয়। হাতুড়িটিকে "ধীর" করে তোলে না বা এটি যে কাজের জন্য ডিজাইন করা হয়েছে তার জন্য কম দরকারী নয়।

একটি সাধারণ প্রোগ্রামিং ভাষা হিসাবে, জাভা অনেকগুলি (যদি না হয় তবে) বিস্তৃত প্রোগ্রামিংয়ের কাজের জন্য সমান। নির্দিষ্ট, তুচ্ছ পরীক্ষা রয়েছে যার জন্য জাভা হ্যান্ড-কোডড সমাধানগুলিকে কম পরিশীলিত ভাষায়, যেগুলি "ধাতুর নিকটবর্তী", তুলনায় কার্যকর করবে না।

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


3

জাভা একটি উচ্চ-স্তরের ভাষা এবং আজকাল এর খ্যাতি অন্যান্য, তুলনামূলক উচ্চ-স্তরের ভাষার সাথে পারফরম্যান্স করা।

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

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

  3. অন্যভাবে, এই জাভা একটি উচ্চ পর্যায়ের ভাষা না থাকার হয় জঞ্জাল সংগ্রহ । আবর্জনা-সংগ্রহগুলি তাদের প্রয়োজনগুলির সমস্ত মেমরি একবারে বরাদ্দকারী প্রোগ্রামগুলির তুলনায় mallocএবং ধীরে ধীরে হতে পারে free। সমস্যাটি হ'ল যে ভাষাগুলিতে আবর্জনা-সংগ্রহ নেই, প্রোগ্রামাররা কেবল প্রোগ্রাম যা তাদের একবারে প্রয়োজনীয় সমস্ত মেমরি বরাদ্দ করে এবং ব্যর্থ হয় যদি কিছু স্বেচ্ছাসেবী সর্বাধিক আকারের ধ্রুবকটি ওভারফ্লাউন হয়ে যায়। সুতরাং তুলনা কমলা থেকে আপেল হয়। প্রোগ্রামাররা যখন নন-জিসি ভাষায় জড়িত কাঠামোর গতিশীল বরাদ্দ দিয়ে প্রোগ্রামগুলি লেখার এবং ডিবাগ করার চেষ্টা করে, তারা কখনও কখনও দেখতে পান যে তাদের প্রোগ্রামগুলি আর কোনও জিসি ভাষার চেয়ে দ্রুততর হয় না, কারণ লেখার ঝোঁক রাখেন না ! তাদের ওভারহেডও রয়েছে ... প্লাস, কাকে কী মুক্তি দেয় তা নির্ধারণ করার জন্য কোনও জিসি বাহিনী না থাকা এবং কোন কোন সময় কী কাকে মুক্তি দেয় তা নির্দিষ্ট করে আপনাকে অনুলিপি তৈরি করতে বাধ্য করে - যখন বেশ কয়েকটি ফাংশন ডেটার প্রয়োজন হবে এবং এটি পরিষ্কার নয় যে কোনটি এটি সর্বশেষ ব্যবহার করা হবে - যেখানে কোনও সিসি ভাষায় অনুলিপি করা প্রয়োজন হত না।malloc এবংfree


1. সম্ভবত হটস্পটের সাথে সত্য নয়। ২. যদি আপনি পদ্ধতিটিকে সিঙ্ক্রোনাইজড হিসাবে চিহ্নিত করেন তবেই।
উইনস্টন ইওয়ার্ট

1
1. সংকলক কোডটি অনুকূলিত করে না, তবে জেভিএম কেবলমাত্র এক বা দুটি ভার্চুয়াল পদ্ধতি সাধারণত ডাকা হয় তা নির্ধারণের জন্য যথেষ্ট স্মার্ট এবং এগুলি স্থিরভাবে কল করতে বা এমনকি ইনলাইনও করতে পারে। আমি নিশ্চিত যে সি ++ ভার্চুয়াল পদ্ধতিগুলিকে ইনলাইন করতে পারে না pretty ২. প্রতিটি জাভা অবজেক্টের একটি লক থাকে। এটিতে প্রতিটি বস্তুতে একটি ছোট ওভারহেড (প্রায় একটি বাইট) থাকে তবে ব্যবহার না করা হলে এর খুব কম প্রভাব পড়ে। ৩. জাভাতে আপনি একবারে আপনার প্রয়োজন সমস্ত বস্তু বরাদ্দ করতে পারেন। এটি আপনাকে এমন অ্যাপ্লিকেশন দিতে পারে যা সারা দিন জিসি না করে। ;) জাভার জিসি সুস্পষ্টভাবে বহু-থ্রেডযুক্ত, এমন কিছু যা সি ++ তে বিশেষ গ্রন্থাগারগুলির প্রয়োজন।
পিটার লরে

সি ++ ভার্চুয়াল কলগুলিকে ইনলাইন করতে পারে, তবে জাভা আরও ক্ষেত্রে এটি করতে পারে এবং মেগামোরিক কল সাইটগুলি অনুকূলকরণের সাথে আরও শক্তিশালী।
পাইওটার কোয়াকজকোভস্কি

2

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


এটি কি জিসির পিছনে প্রযুক্তির কারণে ছিল? আমি জানি তাদের জিসি পর্যায়ে আরও দক্ষ হওয়ার জন্য কিছু কৌশল রয়েছে (বস্তুর জন্য প্রজন্মের স্তরগুলির মতো)। তখন কৌশল কী ছিল?
স্টেফানো বোরিনি

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

2
আধুনিক জিসি অ্যালগরিদমগুলি দুর্দান্ত তবে আমি মনে করি যে সবচেয়ে বড় উন্নতি ছিল জেআইটি।
পাস্কাল থিভেন্ট

1

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

অনেকগুলি (বেশিরভাগ) লোকেরা সাধারণীকরণ করতে পছন্দ করে তাই তারা "জাভা ধীর" বলে কারণ তারা বুঝতে পারে যে অ্যাপগুলি যখন তাদের সাথে যোগাযোগ করে তখন ধীর গতিতে থাকে।


আপনি কি মনে করেন উচ্চ স্মৃতিশক্তি খরচ সরঞ্জাম থেকে বা জাভা লাইব্রেরি থেকে আসে?
স্টেফানো বোরিনি

ইক্লিপ্সের ক্ষেত্রে - অ্যালেক্সের অবকাঠামো থেকেই। অতীতে "ভারী" জিইউআইয়ের জন্য একই কথা (জেবিল্ডার যেমনটি আমি মনে করি)। আমার এক মাতাল অনুভূতি আছে কারণ এটি স্ট্যাটিকালি টাইপ করা ভাষায় প্লাগইন আর্কিটেকচার (যেমন Eclipse এর মতো) ব্যবহার করার জন্য প্রচুর বয়লারপ্ল্যাট বস্তুর প্রয়োজন। Emacs এর পাশাপাশি প্লাগইন রয়েছে এবং সাধারণ কোডিং করার সময় এর মেমরির গ্রহ গ্রহণের চেয়ে 10-20x কম হয়। ইমাস লিস্প কোডটি বাইকোডে সংকলিত হয় এবং ইম্যাক্স ইনডেন্সে লোড করা হয়, তারপরে রান করুন - জাভা ক্লাসলোডারের সমান। আমি জাভাতে অনুমান করি যে কিছু প্লাগযোগ্যতার জন্য মঞ্জুরিপ্রাপ্ত টন মধ্যবর্তী বস্তু রয়েছে।
ওয়াজিয়াচ ক্যাকজমারেেক 20

1

জাভা অ্যাপ্লিকেশনগুলির সাথে বড় সমস্যাটি হ'ল স্টক রানটাইম লাইব্রেরির বিশাল আকারের কারণে এটি বিশাল । বিশাল প্রোগ্রামগুলি স্মৃতিতে প্রচুর পরিমাণে পূর্ণ হয় এবং অদলবদল করে, যার অর্থ তারা ধীর হয়ে যায়।

সান জেভিএম বড় হওয়ার কারণ হ'ল এটির খুব ভাল বাইট কোড দোভাষী রয়েছে যা অনেক কিছুই ট্র্যাক করে কাজ করে। এর অর্থ অনেক বেশি ডেটা, যার অর্থ স্মৃতি।

আপনি জামভিম ভার্চুয়াল মেশিনটি দেখতে চাইতে পারেন যা একটি যুক্তিসঙ্গত দ্রুত দোভাষী (কোনও নেটিভ কোড নেই) এবং খুব ছোট। এটি এমনকি দ্রুত শুরু হয়।


1

পাস্কাল যেমন বলেছেন, জাভা অন্যান্য উচ্চ-স্তরের ভাষার সাথে সমান। যাইহোক, যে কেউ উইন্ডোজ 98- তে মূল জেভিএমগুলির সাথে কাজ করেছিলেন , সেই সময় জাভা ভার্চুয়াল মেশিন দ্বারা সরবরাহিত বিমূর্ততার স্তরটি ছিল, আমরা কি বলব, বেদনাদায়ক?

মূলত, এটি JVM- এ আমরা মঞ্জুরিপ্রাপ্ত যা কম বা কোনও অপ্টিমাইজেশন সহ সফ্টওয়্যার অনুকরণ ছিল।


0

লোকেরা সাধারণত "এটি ব্যাখ্যা করা" লাইনটি খুঁজে বের করে। কারণ একসময়, এটি ছিল এবং খারাপ প্রেসগুলি এমন লোকদের দ্বারা হস্তান্তরিত হয় যারা জাভাটিকে 'খুব ধীর' ​​বলে ফেলেছিল এবং নতুন সংস্করণগুলির পরীক্ষা করতে কখনও ফিরে আসে নি।

অথবা সম্ভবত "লোকে বোকা" আরও ভাল উত্তর।


0

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


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

উত্তরের জন্য ধন্যবাদ, জেআইটি সংকলকরা তাদের সামান্য সময় নিয়ে ভাবেন নি।
হেল্পারমেডোড

আপনার মানে, হটস্পট অভিযোজিত অপ্টিমাইজেশনের মতো কিছু?
স্টেফানো বোরিনি

2
@ بابিএমসিজি: খুব সঠিক। এর সমস্ত ক্রিয়াকলাপের প্রোফাইল প্রতিক্রিয়া সহ ধীরে ধীরে চলতে একটি সি ++ প্রোগ্রাম তৈরি করা যেতে পারে। তারপরে সংকলকটি অর্ধ ঘন্টা সিপিইউ সময় এবং 2 জিবি র‌্যাম ব্যবহার করে খুব দ্রুত সংস্করণটি পুনর্নির্মাণ করতে বিনামূল্যে free এমন একটি জেআইটি যা ব্যবহারকারীদের ছেড়ে চলে যেতে বাধ্য করে।
জ্যান লিংস

1
সার্ভারের মতো দীর্ঘ চলমান অ্যাপ্লিকেশনগুলির জন্য জেআইটি সংকলনের সময় নগণ্য। কমপক্ষে 2 কারণে জেআইটির তুলনায় পিজিওর সাথে এওটি আরও সীমাবদ্ধ। প্রথমত, বেশিরভাগ পারফরম্যান্স পার্থক্য লাইটওয়েট অপটিমাইজেশন দ্বারা অর্জন করা হয়। Gcc -O2 এর সাথে gcc -O3 এর তুলনা করুন। বেশিরভাগ সময় কোনও তফাত থাকে না , কখনও কখনও -O3 ​​কিছুটা ভাল হতে পারে, কখনও কখনও সামান্য খারাপ হতে পারে, তবে আমি এর থেকে> 2x পার্থক্যটি কখনই অনুভব করতে পারি নি। দ্বিতীয়ত, এমনকি পিজিওর সাথেও এওটি ব্যবহার করে আপনি কেবল অনুমান করতে পারবেন যে ব্যবহারের সাইটে প্রোফাইলটি কী হবে। ভুল অনুমান করুন এবং আপনি জেআইটি থেকে অনেক পিছনে রয়েছেন। এবং প্রকৃত প্রোফাইলটি চূড়ান্তভাবে কনফিগার নির্ভর হতে পারে।
পাইওটার কোয়াকজকোভস্কি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.