कमांड लाइन की तुलना में इंटेलिजे में मेरा एप्लिकेशन तेजी से क्यों चल रहा है?

Question

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

mvn clean test -Dtest=MyTest के साथ किया गया परीक्षण, 34 मिनट में चलाया गया।

हम फ़ाइलों को सॉर्ट करने के लिए /bin/sort पर कॉल कर रहे हैं। ऐसा लगता है कि इस तरह का समय लगता है। मुझे समझ में नहीं आता कि क्या अलग है।

इंटेलीजे को देखते हुए यह

/Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/bin/java -Didea.launcher.port=7532 -Didea.launcher.bin.path=/Applications/IntelliJ IDEA 10.app/bin -Dfile.encoding=UTF-8 -classpath %classhpath% com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 -junit4 xxx.IntTestImportProcess,testImportProcess 

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

यहां मेरी मुख्य कक्षा है और मैं दोनों कैसे चल रहा हूं।

public static void main(String... args) throws IOException { 
     if(args.length != 2) { 
      System.out.println("Usage: \n java -jar client.jar spring.xml data_file"); 
      System.exit(1); 
     } 
     ApplicationContext applicationContext = new FileSystemXmlApplicationContext(args[0]); 
     PeriodFormatter formatter = new PeriodFormatterBuilder() 
       .appendMinutes() 
       .appendSuffix("minute", "minutes") 
       .appendSeparator(" and ") 
       .appendSeconds() 
       .appendSuffix("second", "seconds") 
       .toFormatter(); 
     URI output = (URI) applicationContext.getBean("workingDirectory"); 
     File dir = new File(output); 
     if(dir.exists()) { 
      Files.deleteDirectoryContents(dir.getCanonicalFile()); 
     } 
     else { 
      dir.mkdirs(); 
     } 
     ImportProcess importProcess = applicationContext.getBean(ImportProcess.class); 
     long start = System.currentTimeMillis(); 
     File file = new File(args[1]); 
     importProcess.beginImport(file); 
     Period period = new Period(System.currentTimeMillis() - start); // in milliseconds 
     System.out.println(formatter.print(period.toPeriod())); 
    } 

मैं JUnit दूर करने के लिए और सिर्फ एक main() प्रणाली का उपयोग फैसला किया है। नतीजा बिल्कुल वही है। IntelliJ फिर से है। पागल लॉग यहाँ है।

इंटेलीजे

साथ

DEBUG [ main] 2011-08-18 13:05:16,259 [er.DelimitedTextUnixDataSorter] Sorting file [/Users/amirraminfar/Desktop/import-process/usage] 
DEBUG [ main] 2011-08-18 13:06:09,546 [er.DelimitedTextUnixDataSorter] Sorting file [/Users/amirraminfar/Desktop/import-process/customer] 

जावा जार

DEBUG [ main] 2011-08-18 12:10:16,726 [er.DelimitedTextUnixDataSorter] Sorting file [/Users/amirraminfar/Desktop/import-process/usage] 
DEBUG [ main] 2011-08-18 12:15:55,893 [er.DelimitedTextUnixDataSorter] Sorting file [/Users/amirraminfar/Desktop/import-process/customer] 

तरह आदेश

sort -t' ' -f -k32,32f -k18,18f -k1,1n 

है कि आप ऊपर देख सकते हैं, Intellij में छँटाई 1 मिनट लग साथ

लेकिन जावा -जर में 5 मिनट!

अद्यतन

मैं /Library/Java/JavaVirtualMachines/1.6.0_26-b03-383.jdk/Contents/Home/bin/java का उपयोग कर सब कुछ भाग गया और छंटाई अभी भी 5 + अच्छी तरह से मिनट लगते हैं।

Answer 1

मदद करने के लिए सभी को धन्यवाद। यह पता चला है कि IntelliJ LANG=C के साथ क्रमबद्ध होता है। UTF8 में डिफ़ॉल्ट रूप से मैक ओएस एक्स टर्मिनल प्रकार प्रदर्शन करता है जो प्रदर्शन हानि बताता है। उम्मीद है कि यह जवाब किसी की मदद करेगा।

Answer 2

mvn clean परियोजना का पुनर्निर्माण कर रहा है? क्या आईडीईए के तहत रन ऐसा नहीं कर रहा है? मेवेन के साथ परियोजना का निर्माण 18 मिनट लेता है (अगर यह किया जाता है तो मुझे आश्चर्य नहीं होगा, क्योंकि मैवेन पूर्ण गड्ढे है)?

यदि इन सभी सवालों के जवाब 'हां' हैं, तो मुझे लगता है कि आपके पास निष्कर्ष है।

समाधान मैवेन को जंगल में ले जाना, इसे शूट करना, फिर इसे एक अज्ञात कब्र में दफना देना है।

Answer 3

यह प्रश्न बिल्कुल सही ढंग से परिभाषित नहीं है और स्पष्ट से बहुत दूर है। क्या आप कह रहे हैं कि आप Java IO का उपयोग कर किसी फ़ोल्डर में फ़ाइलों की एक सूची पढ़ते हैं और फिर उन्हें सॉर्ट करने के लिए बाहरी प्रक्रिया में पास करते हैं? मेरे लिए थोड़ा अजीब समाधान के रूप में लगता है, लेकिन वैसे भी, यह स्मृति से संबंधित होना चाहिए। JConsole का उपयोग करके दोनों ऐप्स से कनेक्ट करें और चार्ट में सुराग ढूंढें।

Answer 4

mvn शायद आपके आईडीई की तुलना में विभिन्न विकल्पों के साथ एक JVM लॉन्च कर रहा है।

Real differences between "java -server" and "java -client"? लंबे समय तक चलने वाले अनुप्रयोगों के प्रदर्शन में काफी अंतर पैदा कर सकता है, लेकिन कभी-कभी जीसी झंडे में मतभेद प्रदर्शन अंतरों का कारण बन सकते हैं जब आपका ऐप विभिन्न तरीकों से स्मृति का उपयोग करता है।

यदि आपकी प्रक्रिया मेमोरी बाध्य है और कुछ मेमोरी स्तर पर इतनी थ्रैश होती है, तो -Xmx जैसे ढेर झंडे प्रदर्शन को भी प्रभावित कर सकते हैं। मेमोरी प्रोफाइलिंग आसानी से इन या बाहर शासन कर सकती है।

इन मतभेदों का निदान करने के लिए, अपने mvn कॉन्फ़िगरेशन फ़ाइलों को यह पता लगाने के लिए देखें कि यह एक JVM लॉन्च कैसे कर रहा है, और अपने आईडीई जावा ऐप लॉन्चर कॉन्फ़िगरेशन को देखें।

Answer 5

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

एक बहुत आई/ओ बफरिंग पर निर्भर हो सकता है:

Answer 6

एक प्रमाण जवाब की तुलना में अधिक लगता है। 500K से अधिक रिकॉर्ड सॉर्ट करने के लिए बहुत सारे डेटा आउटपुट होने जा रहे हैं, इसलिए सही बफर आकार बहुत मायने रख सकता है। मुझे लगता है कि टीटी आमतौर पर लाइन buffered है, तो यह 500K पढ़ने के लिए जा रहा है & ओपे लिखो, और आईडीई बस बड़े बड़े बफर में पढ़ सकते हैं।

इसके अतिरिक्त, यह संभव है कि ओएसएक्स की प्रक्रिया या आई/ओ शेड्यूलिंग है जो कंसोल वाले लोगों पर जीयूआई ऐप्स का भारी समर्थन करती है (जिसे टीटीआई के जरिए पाया जा सकता है), तो हो सकता है कि आपको & निष्क्रिय रहना पड़े आईडीई के भीतर से कंसोल से बहुत अधिक समय।