क्यों लोग अभी भी कहते हैं कि जावा धीमा है? [बन्द है]

61

एसओ और अन्य स्थानों में लंबे समय तक जावा के धीमे रहने की प्रतिष्ठा है। से मजाक करने के लिए कई टिप्पणियां सवाल और जवाब में, लोगों को अभी भी जावा धीमी गति से पूरी तरह से 90 के दशक में इसके साथ अनुभव पर आधारित है विश्वास करते हैं।

यह मेरा मुद्दा है: हमने इस कारण (अधिकांश) को अस्वीकृत कर दिया है कि लोग मानते हैं कि जावा धीमा है। छोटी चीजों के बाहर, जावा बहुत तेज है।

तो ऐसा क्यों है कि लोग अभी भी जावा को फास्ट मानने से इनकार कर रहे हैं? क्या यह उनकी मानसिकता का हिस्सा है कि कुछ भी C / C ++ धीमा नहीं है? क्या इसलिए कि लोग समय के साथ जाँच नहीं करते हैं? क्या इसलिए कि लोग सिर्फ पक्षपाती हैं?

java performance

— TheLQ
स्रोत

10

उम्म, सी # तेज है;)

— इवान प्लाइस

12

उम, वह लिंक जावा को धीमा नहीं करता है।

13

मेरी भावना है कि जावा धीमी गति के बजाय गैर-जिम्मेदार है।

— zneak

23

फूला हुआ और भयानक यूआई लाइब्रेरी ..?

— dmp

4

क्योंकि JVM कर्नेल का हिस्सा नहीं है। ओह, शायद कुछ लिनक्स लोग इसे भविष्य में जोड़ देंगे।

— क्ले Jéléi

131

यह अनुप्रयोग है। आप ध्यान दें के रूप में, हम है साबित कर दिया, बार-बार, कि काल्पनिक परिदृश्यों में जावा कोड को पूरा या यहाँ तक कि कर सकते हैं हरा सी, सी ++, लिस्प, VB6, या JavaScript की तरह तथाकथित "performant" भाषाओं के प्रदर्शन। और जब इस तरह के सबूतों के साथ प्रस्तुत किया जाता है, तो अधिकांश समझदार, खुले दिमाग वाले अपने सिर शर्म से झुकाएंगे और इस तरह की बदनामी फैलाने का वादा कभी नहीं करेंगे।

... लेकिन फिर, वे ग्रहण, या NetBeans, या Guiffy को आग लगाते हैं, या अपने ब्राउज़र में जावा समर्थन को सक्षम करते हैं, या अपने पसंदीदा फीचर फोन पर एक ऐप चलाने की कोशिश करते हैं। और वे इसके प्रति उत्तरदायी बनने की प्रतीक्षा करते हैं ...

... और प्रतीक्षा करें ...

... और प्रतीक्षा करें ...

... और प्रतीक्षा करें ...

... और प्रतीक्षा करें ...

... और ...

... मैंने जो वादा किया था उसे फिर कभी नहीं करने के लिए ? क्षमा करें, दर्जन बंद होना चाहिए ...

— Shog9
स्रोत

44

यहां तक कि सबसे सरल जावा GUI को शुरू होने में कम से कम 1.5 सेकंड लगते हैं। यह एक छोटा सा नहीं है।

— पीटर बॉटन

32

मैंने कभी नहीं सोचा था कि जावास्क्रिप्ट को "प्रदर्शनकारी" भाषा माना जाता है।

— zneak

11

आईडीई का उल्लेख करने के लिए +1। ग्रहण की जवाबदेही और विजुअल स्टूडियो जैसी आईडीई के बीच बहुत बड़ा अंतर है।

— मध्याह्न काल

56

मेरे पास इसके मुद्दे हैं। फ़ायरफ़ॉक्स मुख्य रूप से C ++ और इसकी धीमी गति से लिखा गया है। क्या इसका मतलब है कि C ++ धीमा है? नहीं, इसका मतलब है कि फ़ायरफ़ॉक्स धीमा है। यह कहना कि एक भाषा धीमी है क्योंकि इसमें लिखा गया सबसे बड़ा कार्यक्रम धीमा है।

— एलएलक्यू

13

जोनास, सबसे सरल उदाहरण का उपयोग करके मैं पा सकता हूं कि मुझे एक बुरा प्रोग्रामर नहीं बनाया गया है। यदि आपको एक जादू की विधि मिली है जो एक ब्लिंक से कम में जावा जीयूआई चलाता है, तो आगे बढ़ें और इसे प्रदर्शित करें ।

— पीटर बॉटन

48

यह प्रश्न झूठे परिसर में संचालित होता है: जहां यह मायने रखता है, जावा अभी भी धीमा है। जहाँ यह गिना जाता है कि बड़े डेटा सेट पर गणना-भारी एल्गोरिदम हैं। दी गई, इन्हें अनुकूलित किया जा सकता है, कभी-कभी सी / सी ++ कोड के बराबर किया जा सकता है, लेकिन केवल प्रतिरूपता और सामान्यता की कीमत पर। कुशल C ++ कोड को सामान्य-प्रयोजन पुस्तकालय के रूप में सामान्य और प्रयोग करने योग्य बनाया जा सकता है। जावा कोड नहीं हो सकता। बस भारी अनुकूलित Array.sortविधि को देखें, जो सभी मौलिक प्रकारों के लिए अलग-अलग कार्यान्वयन का उपयोग करता है, और जिसका ऑब्जेक्ट संस्करण अभी भी C ++ 'जेनेरिक की तुलना में बहुत धीमा है, sortक्योंकि इन वस्तुओं को गतिशील रूप से समानता तुलना को भेजना है।

हॉटस्पॉट इंजन द्वारा किए गए समय के अनुकूलन के अनुसार, वास्तव में, इन आभासी कॉलों के लक्ष्य का अनुमान लगा सकते हैं और इनलाइनिंग का प्रयास कर सकते हैं। लेकिन यह अभी भी सीधे इनलाइन कॉल की तुलना में धीमा है जो C ++ ' sortविधि के अंदर भेजा गया है ।

मेरे एक पूर्व सहयोगी ने एक विशाल सी + + कार्यान्वयन और एक वस्तु-उन्मुख जावा कार्यान्वयन के साथ विशाल डेटा सेट ( गतिशील आकृतियों का उपयोग करते हुए q -gram गिनती) पर एक समस्या के तुलनात्मक मानदंड किए हैं। जावा कोड C ++ कोड की तुलना में कम परिमाण का आदेश था।

बेशक यह संतरे के साथ सेब की तुलना कर रहा है। लेकिन मुद्दा यह है कि जावा कार्यान्वयन सबसे अच्छा संभव कार्यान्वयन था (प्रदर्शन के संदर्भ में, पुस्तकालय के लिए आवश्यक मॉड्यूलरता की डिग्री दी गई), और इसलिए सी ++ कार्यान्वयन था।

दुर्भाग्य से, बेंचमार्क डेटा स्वतंत्र रूप से उपलब्ध नहीं है, लेकिन दूसरों ने रनटाइम एब्स्ट्रक्शन के ओवरहेड की तुलना करते समय समान संख्याएं पाई हैं। उदाहरण के लिए, स्कॉट मेयर्स सी के सामान्य कार्य के ओवरहेड के बारे में प्रभावी एसटीएल में लिखते हैं qsort:

C ++ का क्रम लगभग हमेशा C के क्षोभ को शर्मिंदा करता है जब यह गति की बात आती है। […] रनटाइम के दौरान, सॉर्ट अपने तुलनात्मक फ़ंक्शन के लिए इनलाइन कॉल करता है… जबकि qsort अपने तुलनात्मक फ़ंक्शन को एक पॉइंटर के माध्यम से कॉल करता है। […] एक लाख डबल्स के वेक्टर पर मेरे परीक्षणों में, [क्रमबद्ध] ६ In०% तेजी से भाग गया…

— कोनराड रूडोल्फ को दर्शाता है
स्रोत

6

निष्पक्ष होना, उन std::sortमामलों में से एक है जहां अन्य भाषाओं में कुछ भी ऐसा करना मुश्किल है। लेकिन मैंने देखा है परियोजनाओं के विशाल बहुमत std::sortकोड की तरह लेखन नहीं कर रहे हैं । वे C ++ में जावा कोड (खराब) लिख रहे हैं और शिकायत कर रहे हैं कि उन्हें समस्या है।

— बिली ओनेल

2

क्या आपके पास अपनी कहानी का बैकअप लेने के लिए कोई रिपोर्ट है कि विशाल डेटासेट धीमे हैं? मैंने सुना है कि लोग 1-2 मिलियन एंट्री लिस्ट में ऑपरेशन करने की बात कर रहे हैं और यह अभी भी तेज है। और स्मृति में बड़े पैमाने पर डेटासेट के साथ खिलवाड़ नहीं कर रहा है (आमतौर पर सामान जो कि एक DB में है) एक आला क्षेत्र का एक सा है?

— TheLQ

8

@ THELQ: स्रोत गोगोल-डोरिंग एंड रेनर्ट की किताब सीकॉन है। और आपके काउंटर-उदाहरण के बारे में: क्या संचालन? और वे "उपवास" को क्या मानते हैं? इसके अलावा, 1E6 प्रविष्टियाँ वह सब बड़ी नहीं हैं। ;-) और क्या यह एक आला क्षेत्र है - निश्चित रूप से। लेकिन यह वह जगह है जहाँ आपको तेज़ संगणनाएँ चाहिए। मुद्दा यह है कि क्या जावा तेज है , यह नहीं कि क्या यह सस्ती कार्रवाई के लिए पर्याप्त "तेज" है। एक छोटे से पर्याप्त डेटा सेट पर, सब कुछ काफी तेजी से होता है।

— कोनराड रुडोल्फ

2

सबसे अच्छा संभव कार्यान्वयन

— जेरेमी-जॉर्ज

3

@fonzo उचित सन्निकटन हो सकता है। स्क्रैच कि, एक सरल पर्याप्त एल्गोरिथ्म और एक अच्छी तरह से परिभाषित मीट्रिक के लिए वहाँ कर सकते हैं एक सबसे अच्छा संभव कार्यान्वयन हो। यहां भी यही हाल है। एल्गोरिथ्म सरल है, और एक अच्छी तरह से परिभाषित मामला है जिसके लिए अनुकूलित किया गया था: किसी दिए गए इनपुट पर समय चल रहा है।

— कोनराड रुडोल्फ

28

क्योंकि यह धीमी है ... कुछ अनुप्रयोगों में। डेस्कटॉप अनुप्रयोगों को शुरुआत से ही उत्तरदायी होना पड़ता है और स्टार्टअप ओवरहेड धीमी गति से गिना जाता है।

दूसरी ओर यदि आप एक सर्वर चलाते हैं तो इससे कोई फर्क नहीं पड़ता कि क्या कुछ हीटिंग (JIT विश्लेषण और संकलन) है - आप इसे एक बार ब्लू मून में करते हैं इसलिए अधिकांश समय इसे पूरी तरह से धीमा नहीं माना जा सकता है।

— Maciej Piechotka
स्रोत

स्टार्टअप की लागत एक समस्या है, लेकिन आप इसे कुछ कमांड लाइन स्विच के साथ

— जोड़ सकते हैं

22

कमांड लाइन स्विच के बारे में वास्तव में कितने उपयोगकर्ता जानते हैं?

— वाल्टर

17

TheLQ, यदि आप स्विंग / AWT के लिए 1.5s स्टार्टअप देरी को दूर करने के लिए कमांड लाइन स्विच प्रदान कर सकते हैं, तो कृपया आगे बढ़ें और इसका उत्तर दें: stackoverflow.com/questions/508723/…

— पीटर बेटन

6

और यदि मैं एक जावा लिंक वाली लिंक पर क्लिक करता हूं, तो मैं 5 सेकंड के लिए पूरे ब्राउज़र को लॉक करने से बचने के लिए उन कमांड लाइन स्विच को कैसे ट्विस्ट करूं? यह उस तरह की चीज है जो लोगों को जावा को धीमा कहती है, और इससे कोई फर्क नहीं पड़ता कि एक बार लोड होने के बाद यह वास्तव में जल्दी से चलता है।

— रोमन स्टार्कोव

21

मैं यह कहूंगा क्योंकि जब लोगों ने पहली बार इसका सामना किया था, तो यह धीमा था। उसके आधार पर, उन्होंने इसका एक छाप बनाया। यदि वे इसका उपयोग नहीं करते हैं तो यह धारणा बदलने की संभावना नहीं है, और वे उस धारणा के कारण इसका उपयोग नहीं करते हैं - यह एक दुष्चक्र है।

मुझे स्वीकार करना चाहिए, मुझे यह आभास था कि जावा धीमा था, और हाँ, यह मेरे पिछले प्रदर्शन से था। मैं अब अलग-अलग भाषाओं में चला गया हूं और तब से जावा के लिए बेहद सीमित जोखिम है। नतीजतन, मेरी राय ज्यादा नहीं बदली है।

— Damovisa
स्रोत

3

+1 - मैं पूरी तरह सहमत हूं। मुझे अपने शुरुआती दिनों में जावा से नफरत थी। .NET फ्रेमवर्क ने वास्तव में प्रबंधित कोड कारण की मदद की: मुझे C # पसंद आया और अंततः मैंने जावा की भी सराहना की।

— जादूगर

7

अभी भी हैलो दुनिया को चलाने में एक सेकंड का समय लगता है। यह स्टार्टअप के समय के हिसाब से धीमा है।

— intuited

@intuited C ++ / C # या जो भी भाषा आपको मिल सकती है, उसके ऊपर एक सर्वर बनाने की कोशिश करें, C और THEN के साथ इसे बनाने की कोशिश करें JAVA के खिलाफ तुलना करें। सी के साथ बात यह है कि यह तेज़ है यदि आप "मा" हैं, तो मैंने 10 पंक्तियाँ लिखीं सी कोड जो तेज़ है तो जावा लेकिन आप इसे नहीं पढ़ सकते हैं "प्रकार का आदमी। जिस समय आपका C कोड बढ़ता है, आपकी गति धीमी हो जाती है;)

— AceofSpades

16

क्योंकि यह एक उत्पाद के बारे में लोगों की धारणाओं को बदलने के लिए एक पीढ़ी लेता है

इसका जावा से कितनी तेजी से कोई लेना-देना नहीं है। लोगों के दिमाग में जावा एक कास्ट आइडेंटिफ़ायर है जो 'स्लो' शब्द से जुड़ा है। इसके बारे में आप या ओरेकल कुछ भी नहीं कर सकते।

बस इस बात से खुश रहें कि ओरेकल ने जावा प्रोग्रामिंग कल्चर (अभी तक) को कुछ भी तोड़- मरोड़ कर या बेवकूफ बनाकर नष्ट नहीं किया है । जैसे कि इसे इस्तेमाल करने के लिए अत्यधिक लाइसेंस लागत वसूलना। या पहले सूर्य के स्वामित्व वाले सॉफ्टवेयर पेटेंट के आधार पर लोगों पर मुकदमा चलाना। :: विलाप ::

मुझे यहाँ नायिका होने से नफरत है, लेकिन जब तक कि ओरेकल और Google अच्छे शर्तों पर जावा संघर्ष का निपटारा नहीं करते हैं, या Google को जावा खरीदने के लिए मजबूर किया जाता है और इसे एक 'उचित' ओपन सोर्स प्लेटफॉर्म बनाता है, जावा अच्छी तरह से बच्चे के होने का तरीका है खेल का मैदान जिसमें जूँ हो। IE, कोई भी इसे 20 फीट के पोल से छूना नहीं चाहेगा।

नोट: बस स्पष्ट होने के लिए, जब मैं कहता हूं कि मैं पीढ़ी के लोगों से बात कर रहा हूं, तो कंप्यूटर शब्द नहीं। IE, जब तक कि धारणा रखने वाले लोग बुढ़ापे की मृत्यु हो जाते हैं या युवा पीढ़ी द्वारा प्रतिस्थापित किया जाता है, तब तक धारणा सही होगी। 5 दशक नहीं 5 साल के संदर्भ में सोचें।

— इवान प्लाइस को प्रकट करता है
स्रोत

2

मुझे लगता है कि Google इतना जावा का उपयोग कर रहा है कि वे इसे खरीद रहे हैं यह एक पूरी तरह से अप्रचलित सिद्धांत नहीं है। मैं शायद इससे खुश हो जाऊंगा।

— बार्ट वैन ह्युकेलोम

1

@donroby: और इन भाषाओं की परवाह कौन करता है? दो दशकों में जावा एक आला भाषा होगी।

— ०२:४४ पर ऐस्क

1

@ पास्क - जावा दो दशकों में अप्रचलित हो सकता है, लेकिन एलआईएसपी अब नहीं है और तब नहीं होगा।

— डॉन रॉबी

2

@ पास्क "प्रोग्रामिंग लैंग्वेज आमतौर पर एक पीढ़ी से ज्यादा नहीं जीती हैं" गुड लॉर्ड मैन, 1 मिलियन डेल्फी डेवलपर्स जो पास्कल है, 5 मिलियन विजुअल बेसिक डेवलपर्स गलत ... पर्ल, लिस्प, फोरट्रान, कोबोल, सी ++ का उल्लेख नहीं है आपके पास है उस टिप्पणी के लिए कोई औचित्य ???

— वास्तव में

2

@ मुख्यतः मुख्यधारा में नहीं। लिस्प, फोरट्रान, कोबोल पर कितने व्यवसाय निर्भर हैं। लिस्प के साथ, यह ज्यादातर अकादमिया में फंसा हुआ है और अन्य भाषाओं की सुविधाओं के लिए एक मॉडल के रूप में उपयोग किया जाता है, कुछ वास्तविक उत्पादन परियोजनाओं के लिए इसका उपयोग करते हैं। फोरट्रान उच्च प्रदर्शन गणितीय मॉडलिंग के लिए एक आला भाषा बन गई है और कोबोल केवल इसलिए बनी हुई है क्योंकि बैंकिंग उद्योग को अपने पुराने / भरोसेमंद कोड को एक नए प्लेटफॉर्म में बदलने के लिए डरा हुआ है। C ++ चमकदार अपवाद है क्योंकि यह अभी भी बहुत व्यापक रूप से उपयोग किया जाता है और आज भी अपनाया जाता है।

— इवान प्लाइस

11

एक कारण यह है कि लोग भरोसा करते हैं कि वे जो देखते हैं उसके बजाय दूसरे क्या कहते हैं ।

जब मैंने पहली बार प्रोग्रामिंग शुरू की थी, तब मुझे बताया गया था कि जावा C ++ की तुलना में "धीमा" है, और जावा का उपयोग क्यों किया जा सकता है क्योंकि यह "सुविधाजनक और आसान" है। यह आमतौर पर माना जाता है कि जावा प्रदर्शन की कीमत पर सुरक्षा और सुविधा लाता है। यहां तक कि जब बाद में C # का आविष्कार किया जाता है, तो लोगों का मानना है कि यह जावा से तेज है क्योंकि यह "मूल" है।

लेकिन सच्चाई यह है कि लोग इसे समझे बिना देखते हैं, यह है कि, ग्रहण, जावा के साथ बनाया गया आईडीई, कक्षा में सबसे तेज आईडीई है। मैंने लगभग सभी मुख्य स्ट्रीम आईडीई का उपयोग किया है, जो एमएस और जीएनयू, बोरलैंड ... से हैं, ग्रहण आईडीई का पूर्ण राजा है, मोटे तौर पर यह तेजी के कारण है।

एक और कारण इसकी लंबी शुरुआत का समय है ।

जावा एक छोटे से ऐप को विकसित करने के लिए उपयुक्त नहीं है जो सिस्टम ट्रे में रहता है, थोड़ी मेमोरी का उपभोग करता है, एक डायलॉग पॉपअप आपको ब्रेक लेने के लिए याद दिलाता है; या एक नोटपैड जिसे आप एक टेक्स्ट फ़ाइल खोलने के लिए उपयोग करते हैं, इसे पढ़ें और इसे बंद करें। यह कुछ BIG पर इस्तेमाल किया जाना चाहिए, एक वेब सर्वर की तरह, जो हमेशा होता है, आप कंप्यूटिंग संसाधन का अनुकूलित उपयोग करें, हर घंटे लाखों अनुरोधों का जवाब दें। या एक IDE जैसे ग्रहण जो हजारों कार्यक्षेत्र फ़ाइलों का प्रबंधन करता है। आपको नहीं पता कि जावा ऐप तब तक तेज़ है जब तक कि यह कम से कम कई घंटों तक नहीं चलता है, मुझे विश्वास है।

— रिवाज है
स्रोत

1

इवेसी हर समय सुस्ती।

— एस्क

28

ग्रहण व्रत? LMAO

— फिन

2

@finnw - अगर आप इसे ट्यून करते हैं। बॉक्स से बाहर और सभी प्लग इन के साथ, जाहिर है यह तेज नहीं होगा। स्पष्ट रूप से इसकी तुलना कभी भी विम या जेडिट या नोटपैड ++ से नहीं की जा सकती है, लेकिन ये "तेज़" या "धीमे" तर्क और कथन एक संदर्भ के बिना निरर्थक हैं।

— luis.espinal

2

@ लुलिस आप इसकी तुलना डेल्फी 7 से कर सकते हैं, जो मुझे नहीं लगता कि यह सब ग्रहण की तुलना में बहुत सरल है। और डेल्फी 7 नोटपैड के रूप में लगभग तेज है। यह पागल है।

— रोमन स्टार्कोव 12

4

@finnw, प्लगइन के zillions के साथ एक IDE के लिए यह बहुत तेज है :)

8

@bown "क्यों लोग अभी भी कहते हैं कि जावा धीमा है?"

क्योंकि वे गूंगे हैं। क्योंकि उनके पास कोई काम का अनुभव नहीं है, लेकिन लगता है कि वे डिक्जस्ट्रा के जीवित अवतार हैं या लिनुस टॉर्वाल्ड के दूसरे आ रहे हैं, ओह मैं दुन्नो। इस तरह की एक मंदबुद्धि बात कहने के कारण बहुत सारे हैं, लेकिन आमतौर पर मूर्खतापूर्ण, विचारहीन व्यक्तिपरक कट्टरता, और भावनात्मक ध्यान-भटकना उनके पीछे लगता है।

आइए इसे नापसंद करें ताकि आप जो कुछ मैंने अभी कहा है उसका सच देख सकें:

सबसे पहले, क्या धीमा है, किस संदर्भ में, किस लिए, किन शर्तों के तहत, किस इंजीनियरिंग / वैज्ञानिक / व्यावसायिक उद्देश्य से ( यह कहने के लिए कि यह चूसा है उनमें से एक नहीं है।) कोई भी व्यक्ति जो किसी भी तकनीक के लिए "X धीमा है" कहता है। X, या बस "X Y है" जहां Y कुछ प्रकार का नकारात्मक कथन है, ऊपर दिए गए किसी भी प्रश्न का उत्तर दिए बिना एक मूर्ख के रूप में खारिज किया जाना चाहिए। इस तरह के बयानों का इंजीनियरिंग में कोई स्थान नहीं है। राजनीति और किशोर चैट रूम में हो सकता है, लेकिन इंजीनियरिंग पर नहीं।

दूसरा, इन गुमराह मूर्खों में से अधिकांश जावा के धीमे होने का रोना रोते हैं क्योंकि ZOMG, उनके ग्रहण को हमेशा के लिए आग में ले जाता है (gee, सभी प्लग इन के साथ चीज़ को लोड करता है, और लगता है कि क्या होता है।) इनमें से अधिकांश मूर्खों को पता भी नहीं होता है। ग्रहण को तेजी से संचालित करने के लिए jvm को ट्यून करना (या उस मामले के लिए किसी जावा अनुप्रयोग के लिए)। यही है, उनके पास प्रदर्शन ट्यूनिंग के बारे में कोई सुराग नहीं है, जो न केवल जावा के लिए, बल्कि किसी भी गैर-तुच्छ प्रणाली के लिए एक वास्तविकता है, चाहे वह हार्डवेयर या सॉफ्टवेयर हो। तो वहीं, वे इस तरह के नासमझ बयान देने के लिए किसी भी तकनीकी वैधता के लिए खुद को अक्षम करते हैं।

तीसरा, आइए विचार करें कि जावा विकास का बड़ा हिस्सा क्या है: बैक एंड ओएलटीपी सबसे पहले और सबसे महत्वपूर्ण; मॉनिटरिंग सिस्टम दूसरा आ रहा है। किसी भी प्रकार का सिस्टम क्लस्टर्स में चलाने के लिए, और महीनों के लिए हफ्तों तक निर्बाध रूप से चलाने के लिए है। क्या यह वास्तव में मायने रखता है कि आपका छोटा ग्रहण या टॉय ऐप लोड होने में एक या दो मिनट का समय लेता है जब वास्तविक जावा ऐप का उद्देश्य विस्तारित अवधि के लिए चलना है? प्रसंग, लोग, प्रसंग।

अंत में, Google और eBay पर OLTP की रीढ़ जावा पर चलती है। मैं विरोधाभास द्वारा एक सबूत के रूप में ले जाऊंगा कि जावा धीमा नहीं है (कम से कम उस स्थिति के लिए जो मामले में है, न कि छोटे खिलौने प्रयोगों के लिए, बेंचमार्क और असत्यवत अनाउंसमेंट साक्ष्य विशेष रूप से यह कहने के उद्देश्य से किए गए कि "तेह एक्स धीमा है, यह बेकार है।"

इंजीनियरिंग है, और कट्टरता है। लगता है कि जो श्रेणी के बयान उन जैसे हैं?

— luis.espinal
स्रोत

19

अगर मुझे जावा को स्वीकार्य रूप से तेज़ चलाने के लिए अपने JVM को ट्यून करना है, जबकि मुझे -O2C ++ प्राप्त करने के लिए कुछ भी नहीं है (सीके अलावा ) स्वीकार करने के लिए तेज़ चलना है, तो जावा धीमा है।

— डेविड थॉर्नले

@ दाविद - स्पष्ट कथन। किसी को पता है कि जावा C ++ की तुलना में धीमा है। यह तार्किक रूप से अनुसरण नहीं करता है कि यह धीमा है, हालांकि। न तो जीसीसी झंडे का उल्लेख टिप्पणी की वैधता देता है। यह केवल कहता है कि it is slower than something else.एक जगुआर चीता की तुलना में धीमा है। कि पूर्व बनाता है slow? कुछ इंजीनियरिंग निष्पक्षता का प्रयास करें और अपने आप से यह पूछें: क्या कोई तार्किक रूप से घोषणा कर सकता है arbitrarily, कि कुछ slowबस इसलिए it is slowerहै क्योंकि कुछ और है without mentioning a context of operationsजो परिभाषित करता है कि क्या है fast enoughऔर क्या है? क्या आप, तार्किक रूप से?

— luis.espinal

5

@ luis.espinal: मैं आपके कारण # 2 का जवाब दे रहा था: लोग कहते हैं कि जावा धीमा है, क्योंकि आपकी राय में, वे जावा को ट्यून करने में विफल रहे हैं। कृपया "स्वीकृत रूप से उपवास" के मेरे उपयोग पर भी ध्यान दें। यह मेरे लिए प्रतीत होता है कि कुछ ऐसा है जो "स्वीकार्य रूप से तेज़" नहीं है, और यह मुझे प्रतीत होता है कि कुछ लोग जो नियमित रूप से दावा करते हैं कि धीमी गति से संभव है कि वह तेजी से स्वीकार नहीं करता है।

— डेविड थॉर्नले

4

@ लुलिस एस्पिनल आपको कान्ट की तरह लगता है :) यहां लोगों ने एक अंतर्निहित धारणा बनाई है कि धीमी गति का मतलब अन्य व्यावहारिक, उत्पादन-तैयार भाषाओं जैसे सी ++ की तुलना में धीमा है। (भौतिकी को याद रखें?) जब आप संभावित ऊर्जा को मापते हैं, तो आप हमेशा इसे किसी जमीन के सापेक्ष मापते हैं। अब आपके व्याकरण के अनुसार, "X गूंगा है" आधारहीन है। और "एक्स नथ से डम्बर है" एक्स को पूर्ण रूप से गूंगा नहीं बनाता है, क्योंकि यहाँ कोई भी एक्स हो सकता है। मैं सहमत हूं कि एक सुस्त धीमी गति से कॉल करना संभ्रांत नहीं है, लेकिन यहां के लोग जो कहते हैं कि "गूंगा" नहीं है, लेकिन सिर्फ ऐसा होता है कि निहित धारणा पर सहमति बनी है।

— यति संगदे

1

@ लुइस हाहा .. अच्छा अवलोकन। (मेरा मानना है कि आप कांट का पुनर्जन्म कर रहे हैं और भी अधिक ठोस हो गया है;)) और इस तरह की चर्चाएँ लौ युद्धों और अनुत्पादक कीस्ट्रोक्स में समाप्त होती हैं ... मेरे अनुसार, हमेशा जो सबसे अच्छा उपकरण से निपटने के लिए लगता है उसी तरह रहना चाहिए काम हाथ में। सहमत, कांत २? : पी

— यति सगड़े १४

8

क्योंकि यह है, क्या हम इस विषय को एक बार और हमेशा के लिए बंद कर सकते हैं?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [टेबल पर स्क्रॉल करें, जावा C ++ की तुलना में 3.7-12.6 गुना धीमा है, Google कर्मचारियों द्वारा शोध]

पुनश्च: यदि यह नहीं है, तो मुझे एक शुरुआत के लिए कम से कम एक तेज़ जावा ऐप नाम दें, पहले एक नहीं देखा।

— चलता है
स्रोत

6

कृपया अपने उत्तर में पीडीएफ की सामग्री को संक्षेप में प्रस्तुत करें।

— एडम लेअर

1

यह शोधपत्र वैज्ञानिक अनुसंधान मानकों से बहुत दूर है। यह सभी भाषाओं में बिल्कुल समान एल्गोरिदम और अनुकूलन की तुलना भी नहीं करता है। "ई। जावा ट्यूनिंग जेरेमी मैनसन ने मूल C ++ संस्करण के साथ जावा के प्रदर्शन को बराबर पर लाया। इस संस्करण को java_pro निर्देशिका में रखा गया है। ध्यान दें कि जेरेमी ने जानबूझकर आगे कोड को अनुकूलित करने से इनकार कर दिया, C ++ के कई अनुकूलन जावा पर लागू होंगे। साथ ही संस्करण। " jeremymanson.blogspot.com/2011/06/scala-java-shootout.html

— पिओट्र कोलक्ज़कोव्स्की

6

TMHO, यह ब्राउज़र में VM को शुरू करने के लिए आवश्यक समय के कारण है। यदि कोई एप्लिकेशन धीरे-धीरे शुरू होता है, तो लोग केवल उसे याद रखेंगे। क्योंकि, लंबे समय तक चलने का समय वास्तव में कष्टप्रद होता है। वास्तव में। मेरे एक सहकर्मी ने मुझे बताया कि वह फ़ायरफ़ॉक्स का उपयोग नहीं करता है क्योंकि यह बहुत धीमा है। (?!?)। लेकिन, हाँ, ठीक है, विंडोज़ पर, फ़ायरफ़ॉक्स को दिखाने के लिए भारी मात्रा में समय लगता है। उनके अनुसार, यह ऐप धीमा है, उन्होंने इसकी सामान्य गति के बारे में अपना मन बनाया।

— पियरे वेलेट
स्रोत

यही कारण है कि मोज़िला फ़ायरफ़ॉक्स को तेजी से शुरू करने के लिए एक भयानक प्रयास खर्च कर रहा है ...

— स्पड 86

2

यह विंडोज की तरह चालू हो सकता है। हां, लॉग इन करने के बाद आप डेस्कटॉप को वास्तव में जल्दी से देख लेते हैं, लेकिन फिर भी आपको प्रतिक्रियाशील होने के लिए कुछ समय इंतजार करना होगा।

— बार्ट वैन ह्युकेलोम

6

क्या तुलना में धीमी? मैं साधारण रूबी से JRuby (जावा आधारित रूबी) में बदलने की सोच रहा हूं क्योंकि मैंने सुना है कि यह तेज है।

— एंड्रयू ग्रिम
स्रोत

1

JRuby है रूबी की तुलना में तेजी, 1.9 में भी। हालांकि, अंतर बंद हो रहा है।

— डैन रोसेनस्टार्क

2

एक बड़ी समस्या को इंगित करने के लिए +1। हालांकि मैं कहूँगा कि ओपी शायद C # या C ++ की तुलना कर रहा है।

— बिली ओनेल

@ यार, आप इशारा कर रहे हैं कि CRuby JRUby के साथ पकड़ बना रहा है?

6

राय राय हैं, और तथ्य तथ्य हैं।

Google कोड जाम का एक तथ्य यह है, जो प्रोग्रामर को कम समय में कठिन कंप्यूटिंग समस्याओं को हल करने के लिए चुनौती देता है, जिसका अर्थ है कि वे जिस भाषा का उपयोग करते हैं उसका प्रदर्शन एक महत्वपूर्ण भूमिका निभाता है:

पिछले संस्करणों के दौरान (2009, 2010, 2011), लगभग 75% प्रोग्रामर जो अंतिम राउंड में पहुंचे थे, C ++ का उपयोग कर रहे थे, जैसा कि जावा का उपयोग करते हुए लगभग 15% था।

स्रोत -> http://www.go-hero.net/jam/

— डैनियल स्कोको
स्रोत

3

यही कारण है कि केवल सच साबित करता है कि जावा सकते रफ्तार केंद्रित प्रतियोगिता के शीर्ष करने के लिए इसे बनाने लेकिन अधिकांश लोगों को सी ++ चुनें।

— एडम लेअर

3

"कम समय में कठिन कंप्यूटिंग समस्याओं को हल करें" - क्या, कोड लिखने में लगने वाला समय, या कोड को चलाने में लगने वाला समय ? बावजूद, आपका तथ्य यह है कि - एक तथ्य - प्रश्न के साथ क्या करना है? क्या आप अपने तथ्य से निष्कर्ष निकाल रहे हैं?

— 13

जो सिर्फ इसलिए हो सकता है क्योंकि फाइनल राउंड बनाने वाले प्रोग्राम लिखने वाले 75% लोगों को लगता है कि जावा बिना कभी टेस्ट किए धीमा है और इसलिए इसके बजाय C ++ का इस्तेमाल करते हैं क्योंकि उनका मानना है कि यह बिना टेस्ट किए ही तेज है।

— jwenting

4

सर्का 1997 में मैंने एक एचपी वेक्ट्रा वीई (200 मेगाहर्ट्ज) और विंडोज 95 का उपयोग किया। अधिकांश एप्लिकेशन इस पर बहुत तेजी से चले, लेकिन फिर मैंने जावा (आईडीई) में लिखे गए कुछ अनुप्रयोगों की कोशिश की, अगर मैं सही तरीके से याद करता हूं)। वे बहुत धीमे थे, कम से कम उनमें से जीयूआई भाग थे। शुरू करने में उन्हें लंबा समय लगा, और GUI तत्व (जैसे मेनू) बहुत प्रतिक्रियाशील नहीं थे - दृश्य प्रतिक्रिया में देरी थी। इसके अलावा, चूंकि जावा GUI अनुप्रयोगों में (विशिष्ट) एक विशिष्ट रूप था, मैंने इस प्रदर्शन (और जावा) को खराब प्रदर्शन के साथ जोड़ना सीखा।

— एंड्रियास रिज्ब्रांड
स्रोत

2

मुझे 1997 याद है! महान वर्ष, हालांकि बहुत सारी मदिरा - और अवलोकन - 1997 से अब उपयोग करने योग्य नहीं हैं।

— डैन रोसेनस्टार्क

1

मुझे 1997 भी अच्छी तरह याद है। विंडोज हर समय दुर्घटनाग्रस्त हो गया और ड्राइवर स्थापित करते समय रिबूटिंग की आवश्यकता थी। कबाड़ का टुकड़ा।

और आपने 1997 की अपनी राय नहीं बदली? क्या आपने देखा कि 2011 1997 की तुलना में पूरी तरह से अलग है?

— जेसपर

5

इस डेटा से मेरा विश्लेषण यह होगा कि 1997 को चूसा गया।

— जेसनट्र्यू

4

यह निर्भर करता है कि आपके धीमे होने का क्या मतलब है।

सबसे पहले, जावा ने हाल ही में कई प्रगति की है और ज्यादातर मामलों में बहुत तेज है। परंतु :

जावा स्टार्टअप पर धीमा है, क्योंकि आपको कुछ भी करने से पहले जेवीएम को लोड करना होगा।
कुछ सुरक्षा सुविधा कुछ मामलों में प्रदर्शन को मार सकती हैं। रैंडम एक्सेस के साथ बाउंड चेक एक अनुकरणीय है।
जावा में वास्तव में तेजी से कुछ करें जेवीएम के खिलाफ काम करने की आवश्यकता है (छूट के लिए कैश लाइन का लाभ उठाने के लिए)।
मेटाप्रोग्रामिंग की कमी प्रत्येक अमूर्तता के साथ रन टाइम पर एक तपस्या का कारण बनती है, इस प्रकार प्रदर्शन कई मामलों में डिजाइन की लागत पर आते हैं।
जावा शायद ही डिजाइन के द्वारा वास्तविक समय की कमी को सुनिश्चित कर सकता है - और इसे कुछ लोगों द्वारा «धीमा" माना जा सकता है।

वैसे, जावा कुछ मामलों में, वेनिला सी / सी ++ से तेज है। लेकिन भाषाएं आपको उन्हें ट्विक करने के लिए उपकरण देती हैं।

जावा एक प्रोग्रामिंग भाषा है जिसका उद्देश्य उत्पादकता है। अब यह अधिकांश अनुप्रयोगों के लिए पर्याप्त तेज़ है, लेकिन कुछ अन्य लोगों के लिए पर्याप्त नहीं है।

सामान्य तौर पर, जावा की सुस्ती एक अति प्रयोगित तर्क है क्योंकि यह ज्यादातर मामलों में अपरिवर्तनीय है।

— deadalnix
स्रोत

2

सरल, विहित जावा कोड साधारण या विहित C / C ++ / D कोड की तुलना में अधिक या समान गति से होता है। सरल, विहित कोड अनावश्यक रूप से बहुत सारे मेमोरी आवंटन करने के लिए जाता है, विशेष रूप से किसी भी सीपीयू आर्किटेक्चर के लिए ट्यून नहीं किया जाता है, इसमें किए गए निम्न स्तर के अनुकूलन के टन नहीं होते हैं, आदि जावा के हॉटस्पॉट जीसी अद्भुत से कम नहीं है, और वीएम ऑप्टिमाइज़ेशन करते हैं। एक स्थिर संकलक क्या कर सकता है की तुलना में बेहतर होना।

दूसरी ओर, यदि आपको वास्तव में प्रदर्शन की आवश्यकता है और इसे प्राप्त करने के लिए हाथ से धुन करने के लिए तैयार हैं, तो C / C ++ / D इसके लिए कई और अवसर प्रदान करता है। आप जावा में इनलाइन असेंबलर का उपयोग नहीं कर सकते। आप बिट्स के सरणियों के रूप में फ्लोटिंग पॉइंट नंबरों का इलाज करने के लिए गंदे प्रकार के चालाक चाल का उपयोग नहीं कर सकते हैं। आप कस्टम मेमोरी प्रबंधन योजनाओं का उपयोग नहीं कर सकते हैं जो आपके विशिष्ट उपयोग के मामले के लिए जीसी से अधिक तेज हो सकती हैं। आप जावा में स्टैक पर लगभग उतना नहीं आवंटित कर सकते हैं जितना कि C / C ++ / D में। जावा में उच्च क्रम वाले कार्यों के बराबर कुछ भी प्राप्त करने का एकमात्र तरीका इंटरफेस और रनटाइम बाइंडिंग है। D और (मुझे लगता है, अगर मैं गलत हूं तो मुझे सुधारें) C ++, आप लचीलेपन के नुकसान के बिना संकलन समय पर होने के लिए बाइंडिंग की अनुमति देते हुए, टेम्प्लेट पास कर सकते हैं।

— dsimcha
स्रोत

5

क्या आप उन टिप्पणियों को स्रोत बना सकते हैं? Ie जहां कोई भी बेंचमार्क प्रत्येक भाषा में विहित कोड दिखा रहा है जो जावा को तेज दिखा रहा है?

— बिली ओनेल

1

जावा के "सुस्ती" के लिए एक और बिंदु 64 बिट रनटाइम है।

मैंने सुना है कुछ लोग शिकायत करते हैं कि 64 बिट कंप्यूटर पर जावा उनके लिए बहुत धीमा है। जैसा कि यह पता चला है, 64 बिट जावा रनटाइम सर्वर जेवीएम का उपयोग करता है जो शुरू होने से पहले पूरे कार्यक्रम को संकलित करता है।

यहां बताया गया है कि 64 बिट वीएम धीमा क्यों शुरू होता है।

विंडोज पर उदाहरण के लिए:

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)

— आंद्रेजाको को दर्शाता है
स्रोत

3

सर्वर VM स्टार्ट-अप के लिए धीमा है, लेकिन यह शुरू होने से पहले पूरे कार्यक्रम को मूल रूप से संकलित नहीं करता है । यह, कक्षाओं को आलसी और संभावित रूप से प्रतिबिंब के माध्यम से लोड नहीं किया जा सकता है, इसलिए अग्रिम में यह जानने का कोई तरीका नहीं है कि बायटेकोड को मूल रूप से संकलित करने की आवश्यकता क्या होगी।

— दान डायर

@ डैन डायर कुछ शोध के बाद, ऐसा लगता है कि मैंने जो कुछ पढ़ा उसे गलत समझा। मेरा मतलब था कि क्लाइंट वीएम अधिक अनुकूलन करता है जबकि ग्राहक त्वरित शुरुआत और छोटे मेमोरी उपयोग के लिए अनुकूलित है।

— आंद्रेजाको

सर्वर वीएम को लंबे समय तक चलने वाली प्रक्रियाओं के लिए अनुकूलित किया जाता है, इसलिए अधिक प्रीलोड करता है जो अधिक स्टार्टअप समय की ओर जाता है और अधिक रैम का उपयोग करता है। क्लाइंट VM निचले पायदान और स्टार्टअप समय के लिए अनुकूलित है, लेकिन इसमें रनटाइम प्रदर्शन कम हो सकता है।

— jwenting

0

जावा का प्रदर्शन बहुत ही व्यक्तिपरक है, क्यों जावा की धारणा बहुत धीमी है इस कारण से कि दूसरों ने नोट किया है: किसी चीज की अधिकांश लोगों की धारणा उसके पहले के अनुभव से रंगी है और जावा हमेशा से एक अच्छी तरह से अनुकूलित भाषा नहीं है हुड। इसी तरह, वेनिला एक्लिप्स विजुअल स्टूडियो जैसी आईडीई की तुलना में जवाबदेही के मामले में काम करने और तालमेल बनाने के लिए वास्तव में तेज आईडीई नहीं है।

हालांकि, यूआई के मुद्दों के बाहर कि जावा में स्टार्ट-अप है, यह अधिकांश अनुप्रयोगों के लिए पर्याप्त तेज़ है। यदि आप खोजते हैं, तो आप उन लेखों को खोज सकते हैं जो अन्य भाषाओं के साथ तुलना करते हैं और प्रस्तुत किए गए अधिकांश परिणाम इसे उस सीमा में डालते हैं जहां यह केवल एक मुद्दा होगा जब आप प्रमुख डेटा सेट के साथ काम कर रहे हैं।

बायोइनफॉरमैटिक्स क्षेत्र में इसका काफी उपयोग किया जाता है क्योंकि यह अच्छी तरह से समर्थित है और इसके लिए पहले से ही एक इंस्टॉलेशन बेस है, जो कि जावा के पास एक फायदा यह है कि आप इसके साथ कुछ काफी तेजी से विकास कर सकते हैं जो आप सी के साथ नहीं कर सकते हैं। यदि आप जैव सूचना विज्ञान के लिए उपयोग की जाने वाली भाषाओं को देखते हैं (मैं व्यक्तिगत रूप से आर, पायथन और जावा का नियमित रूप से उपयोग करता हूं) तो आप ध्यान देंगे कि उनमें से कोई भी वास्तव में सबसे तेज नहीं है और यह जैव सूचना विज्ञान में डेटा सेट के लिए 100 के दशक में चलाने के लिए असामान्य नहीं है। जानकारी के गीगाबाइट। दिन के अंत में, मानव समय अभी भी अधिक मूल्यवान है और जबकि गति अंतर ध्यान देने योग्य हैं, डेटा सेट का आकार काफी बड़ा होता है जो वे वैसे भी रात भर चलाते हैं।

यदि जावा में एक स्नैपी यूआई लिखना आसान था, तो यह काफी हद तक ऐसा है कि गति धारणा रडार से गिर जाएगी क्योंकि ज्यादातर लोग भाषाओं को पर्याप्त धक्का नहीं देते हैं कि गति वास्तव में दैनिक आधार पर एक मुद्दा है।

— rjzii
स्रोत

0

एक बेकार सिक्के में फेंकने के लिए, मुझे लगता है कि जावा वेबएप्स में आम तौर पर लंबे स्टार्टअप और प्रतिक्रिया समय होते हैं, जहां यह मुझे लगता है कि पायथन या रूबी ने बेहतर किया होगा।

मैं अपनी अधिकांश प्रोग्रामिंग के लिए एक्लिप्स का उपयोग करता हूं, और मुझे यह कहना होगा कि जावा कुछ और ही तेजी से है, अगर स्थानीय रूप से तेजी से नहीं चल रहा है और "स्टैंडअलोन"।

— थोमस
स्रोत

1

वेब पर, स्टार्ट अप टाइम उतना महत्वपूर्ण नहीं है। यह संसाधन की खपत और मापनीयता है जो सबसे ज्यादा मायने रखती है।

— बेरिन लोरिट्श

-7

मैं कहूंगा कि जावा असीम रूप से धीमा है, केवल सुस्त नहीं है, क्योंकि यह सरल समस्याओं को हल करने में विफल रहता है जो वास्तविक उच्च स्तरीय भाषाओं में आसान हैं।

मैं एक सरल उदाहरण देता हूं। एक सरल अनुकूलन है जो एक सूची को दो बार मैप करने पर लागू होता है, जिसे वनों की कटाई कहा जाता है: यहां मेरी भाषा में लिखित इसके लिए नियम है:

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

जो कहता है: सूची x को f के साथ मैप करने के बजाय, इसे फिर से g के साथ मैप करना, दो सूची ट्रैवर्स की आवश्यकता होती है और कचरा अस्थायी सूची बनाना होता है, बस फ़ंक्शन की संरचना के साथ सूची को मैप करें।

यह जावा जेवीएम के निम्न स्तर के प्रदर्शन की तुलना में काफी अधिक उच्च स्तरीय अनुकूलन है । ऊपर मैंने जो स्पेसिफिकेशन दिया है, वह सिर्फ बहुत बढ़िया सिंटैक्स नहीं है, यह उपयोगकर्ता द्वारा फेलिक्स कंपाइलर को ऑप्टिमाइज़ करने का तरीका बताते हुए लिखा गया एक निर्देश है।

कृपया मुझे दिखाओ कि जावा में इस तरह की बात कैसे करें। नहीं? फिर जावा धीमा है। बहुत धीमी गति से। [हास्केल यह एक स्वचालित रूप से मैं विश्वास कर सकता हूँ]।

और इससे पहले कि आप कहते हैं "लेकिन जावा एक ओओ भाषा है, इस तरह का अनुकूलन लागू नहीं होता है" .. ठीक यही मेरी बात है। जावा बेकार है, और OO होने का एक मुख्य कारण है।

जेआईटी अनुकूलन कभी भी प्रतिस्पर्धा के करीब नहीं आ सकता है, जो एक प्रकार के अनुकूलन के साथ एक सभ्य संकलक कर सकता है।

— Yttrill
स्रोत

3

मुझे बिल्कुल पता नहीं है कि आपका कोड वहां क्या करता है। और अगर आप कहते हैं कि एक पूरी भाषा सिर्फ इसलिए धीमी है क्योंकि यह एक छोटा अनुकूलन नहीं कर सकता है तो यहां अन्य समस्याएं हैं

— TheLQ

7

-1 एक पुराने सवाल को खोदना और बहुत ही कम तर्क वाली भाषा को कोसना। मुझे बताएं कि क्या आप अपने तर्क के साथ क्या गलत है के बारे में एक विस्तृत लेखन चाहते हैं। शुरुआत के लिए, मुख्य कारण के रूप में OO का नामकरण करना बहुत उद्देश्यपूर्ण नहीं है और एक JVM + JIT का वास्तविक प्रदर्शन बहुत अच्छा है, भले ही वहां अनुकूलन छूट गए हों।

8

हास्केल असीम रूप से हमारे मुख्य मंच के लिए जावा की तुलना में धीमा है, क्योंकि इसे उक्त मंच पर

1

@ Thorbjørn रावन एंडरसन मैं वास्तव में चाहता हूं कि मैं आपको उस अवलोकन के लिए एक +1 दे सकूं।

— पैट्रिक ह्यूजेस