प्रदर्शन महत्वपूर्ण जीयूआई आवेदन (विंडोज़, लिनक्स)

I've been tasked with updating a series of applications which are performance critical VB.NET apps that essentially just monitor and return networking statistics. I've only got three requirements: convert it to C#, make it fast, and make it stable

One caveat is that we "may" migrate from a .NET platform to linux "soon"

भविष्य में इन ऐप्स को बनाए रखने के लिए मैं ज़िम्मेदार हूं इसलिए मैं यह सही करना चाहता हूं। मैंने एमवीपी पैटर्न के अनुसार इन ऐप्स को दोबारा करने का फैसला किया है ताकि मैं ठीक से इस बुरे लड़के से नरक का परीक्षण कर सकूं। लेकिन मैं यह भी सोच रहा था क्योंकि मैं एमवीपी का उपयोग कर रहा था कि मैं देशी सी/सी ++ कोड में कम्प्यूटेशनल रूप से महंगे सामान भी कर सकता हूं जबकि जीयूआई .NET रूपों, या क्यूटी या जो भी हो, के साथ किया जाएगा।

प्रशन:

  1. क्या यह Winforms में एक जीयूआई करने के लिए समझ में आता है लेकिन मूल, अप्रबंधित सी/सी ++ में महंगे सामान?

  2. एक अच्छी क्रॉस प्लेटफ़ॉर्म विंडोिंग किट के लिए कोई अनुशंसा जो ऊपर वर्णित परिदृश्य के लिए उपयुक्त होगी?

0
ro fr bn

12 उत्तर

1) क्या यह Winforms में एक जीयूआई करने के लिए समझ में आता है लेकिन मूल, अप्रबंधित सी/सी ++ में महंगे सामान?

न होने की सम्भावना अधिक। जब तक आप अन्य देशी सी DLLs या इतने पर की एक बहुत कुछ के साथ संवाद स्थापित कर रहे हैं, सी # 5% 5% धीमी बीच होने की संभावना है तेजी सी से ++ (std :: स्ट्रिंग वास्तव में आप अगर आप को मारता है ' यह उपयोग कर रहे हैं)

2) एक अच्छी क्रॉस प्लेटफार्म विंडोिंग किट के लिए कोई सिफारिशें जो ऊपर वर्णित परिदृश्य के लिए उपयुक्त होंगी?

यदि यह बटन के साथ बस कुछ सरल रूप है, तो मोनो उन्हें असम्बद्ध रूप से चलाने में सक्षम होंगे। इन दिनों .NET WinForms के लिए यह समर्थन बहुत अच्छा है। हालांकि, बट बदसूरत है :-)

0
जोड़ा
std :: स्ट्रिंग आपको मारता है? वास्तव में। .NET तारों की तुलना में (और सामान्य हटाएं और नए जीसी को प्रोत्साहित करें) वे बहुत तेज़ हैं। नोट wpf आर्किटेक्ट्स ने प्रदर्शन कारणों से wpf कोड में कई स्ट्रिंग का उपयोग करने की सलाह दी है। (किरण कुमार द्वारा डब्ल्यूपीएफ प्रदर्शन वेबकास्ट के लिए गूगल)
जोड़ा लेखक gbjbaanb, स्रोत

1) समयपूर्व अनुकूलन बुरा है। सी # में अपनी "महंगी सामग्री" को कार्यान्वित करें और देखें कि क्या आपको इसे पुन: सक्रिय करने की आवश्यकता है या नहीं। या, कम से कम एक परीक्षण स्थापित करें जो आपको यह निर्धारित करने की अनुमति देगा।

2) योच। क्रॉस प्लेटफार्म यूआई। मैं "मई" सामान के साथ नहीं रखूंगा। नीचे weasels नाखून; आप जो भी डिजाइन कर रहे हैं उसे जानने के बिना आप डिज़ाइन निर्णय कैसे ले सकते हैं? यदि आप एक शुद्ध .NET कार्यान्वयन के साथ जाते हैं, तो क्या वे शिकायत करेंगे यदि आपको मोनो में काम करने के लिए (कम से कम) रिफैक्टर करना है? यदि आप जावा में इसे बनाते हैं, तो क्या वे नाराज होंगे कि यह नरक के रूप में बदसूरत दिखता है और उपयोगकर्ता शिकायत करते हैं कि वे उन सभी .jars के बीच अपनी .exe फ़ाइल नहीं ढूंढ सकते हैं?

0
जोड़ा

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

आपके दूसरे प्रश्न के लिए, यदि आप किसी बिंदु पर किसी अन्य प्लेटफॉर्म पर जा रहे हैं - तो आप उन पुस्तकालयों पर एक नज़र डालना चाहते हैं जो मोनो द्वारा लागू किए गए हैं ( http://www.mono-project.com/Main_Page ), इसमें क्रॉस प्लेटफॉर्म विंडोिंग के संबंध में आपकी अधिकांश ज़रूरतों को भी शामिल करना चाहिए क्योंकि यह WinForms का समर्थन करता है और जीटीके #।

0
जोड़ा

और फिर, मुझे ज़ोर देना चाहिए, सी ++ सामान वेरिएरीय महंगा है। क्या मैंने उपर्युक्त उल्लेख किया है? (भारी उठाने वाले सी ++ को छिपाने वाले .NET फॉर्म)

जैसा कि पहले उल्लेख किया गया है, मैंने व्यक्तिगत रूप से VB.NET और C# दोनों में लिखे गए अनुप्रयोगों में WinForms के कारण किसी भी प्रणाली को धीमा धीमा नहीं देखा है। हालांकि, यदि एप्लिकेशन वास्तव में गहन प्रदर्शन करता है तो आप सीआईएल में सब कुछ लिखने के कारण सी # में सबकुछ लिखा है ( http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/ )। इस प्रकार, सी # जैसी भाषा में जीयूआई लिखने से विकास का वह हिस्सा थोड़ा आसान हो जाएगा जो आपको कोड के महत्वपूर्ण हिस्सों पर काम करने के लिए और अधिक समय देगा। सी # कोड से सी/सी ++ कोड पर कॉल के कारण यहां केवल एकमात्र पकड़ -22 कुछ धीमा हो सकता है; हालांकि, यह संभावना बहुत कम संभावना है।

0
जोड़ा

First off, I would put some time into trying out a few VB.NET to C# converters. You're basically porting syntax, and there's no reason to do that by hand if you don't have to. Sure, you might have to clean up what comes out of the converter, but that's way better than a by-hand conversion.

अब, आपके प्रश्नों के लिए:

1) क्या यह Winforms में एक जीयूआई करने के लिए समझ में आता है लेकिन मूल, अप्रबंधित सी/सी ++ में महंगे सामान?

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

2) एक अच्छी क्रॉस प्लेटफार्म विंडोिंग किट के लिए कोई सिफारिशें जो ऊपर वर्णित परिदृश्य के लिए उपयुक्त होंगी?

मैं निश्चित रूप से मोनो में देख रहा हूं। यदि आप सी # के साथ जा रहे हैं तो यह वास्तव में सबसे अच्छा है। जब आप लिनक्स में जाते हैं तो यह बहुत अधिक मोनो या दूसरी भाषा में फिर से लिखता है।

0
जोड़ा
विंडोज फॉर्म के सीमित समर्थन पर ध्यान दें - सबकुछ कभी भी समर्थित नहीं हो सकता है।
जोड़ा लेखक Blaisorblade, स्रोत

आप मोनो का उपयोग करना चाहते हैं। यह .NET का एक ओपन सोर्स वर्जन है जो कई प्लेटफॉर्म पर चलता है ... लिनक्स, मैक, सोलारिस, विंडोज, आदि ..

Now about coding your expensive stuff in C/C++. Here's an article that does a very good job explaining the differences between C/C++ & C# performance.

0
जोड़ा
यह देखते हुए कि लेख हाइपर थ्रेडेड निर्देश सेट का उल्लेख करता है, मुझे लगता है कि अधिक विश्वसनीय स्रोत हो सकते हैं।
जोड़ा लेखक Blaisorblade, स्रोत

The c/c++ stuff may end up being a good idea, but right now YAGNI. Same with the Linux stuff. Ignore it, you ain't gonna need it until you need it. Keep it simple. Unit test the hell out of it, as you say. Get the code working and evolve the design from there.

0
जोड़ा
पोर्टेबिलिटी चिंता का विषय हो सकता है जब गैर-पोर्टेबल पुस्तकालयों का उपयोग करना? इसे सरल रखें लागू नहीं होता है। दिए गए किसी भी उचित विकल्प, यूआई के लिए कार्यान्वयन लागत समान है, और यह पोर्टिंग लागत के समान है। वास्तव में, पसंद से पहले WinForms के समर्थन की जांच की जानी चाहिए।
जोड़ा लेखक Blaisorblade, स्रोत
पोर्टेबिलिटी चिंता का विषय हो सकती है, लेकिन यह एक आवश्यकता नहीं है। यह इसे जोड़ने के लिए सोना चढ़ाना है।
जोड़ा लेखक Andrew Cowenhoven, स्रोत

I might be misunderstanding the issue, but if it is a network monitoring system, why isn't it written as a "dedicated" Windows service?

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

0
जोड़ा

नहीं, सी/सी ++ में "महंगे सामान" करने का अर्थ नहीं है। सी # की तुलना में संभावित (और सबसे अधिक मामूली) प्रदर्शन सुधार कभी भी आपकी उत्पादकता को एक अजीब, बीमार मजाक से अधिक नहीं करते हैं। वास्तव में। यह भी करीब नहीं है।

Read through this (and all posts referenced within): http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

0
जोड़ा

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

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

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

gtk-sharp is a pretty nice cross platform toolkit.

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

0
जोड़ा

पीसी आधारित एच/डब्ल्यू परीक्षण उपकरण (जिसका स्पष्ट रूप से "यूआई विकल्प के साथ") का अर्थ है, जो एक एम्बेडेड हार्डवेयर (पीसीएमसीआईए इंटरफ़ेस के माध्यम से) के साथ इंटरैक्ट करता है, के बारे में कुछ समय पहले मुझे इसी तरह की दुविधा थी।

बाधा यह थी कि परीक्षण परीक्षक द्वारा निर्दिष्ट समय से 10ms के अधिकतम विचलन पर चलाना चाहिए।

उदा।: यदि परीक्षक निम्नलिखित परीक्षण अनुक्रम बनाता है:

    1. दूरस्थ रूप से एच/डब्ल्यू
    सक्रिय करें 2. 50 एमएमएस देरी के लिए प्रतीक्षा करें।
    3. एक एच/डब्ल्यू जानकारी पढ़ें।

the delay mentioned in step 2 should not be > 60ms.


I chose C++ WIN32 application as my back-end and VC++ 2005 Winform (.NET platform) for UI development. Detailed information on how to interface these two is available in msdn
I segregated the system like this:
In VC++ .NET:

    1. यूआई के बारे में पूरी जानकारी रखने के लिए यूआई (डब्ल्यू एंड डब्ल्यू के माध्यम से पढ़ें) और मांग पर एच/डब्ल्यू को नियंत्रित करने के लिए। (बटन, कॉम्बो-बॉक्स इत्यादि ..)
    2. यूआई को महत्वपूर्ण परीक्षण अनुक्रम चलाने के लिए यूआई (जैसा ऊपर उल्लिखित उदाहरण में उल्लिखित है) 3. इन सूचनाओं को इकट्ठा करना और एक समय-रेखा प्रारूप में एक स्ट्रीम (फ़ाइल-स्ट्रीम) बनाना (यानी, चरणों के सटीक क्रम में जिसमें इसे निष्पादित किया जाना है)।
    4. WIN32 बैक-एंड एप्लिकेशन के साथ ट्रिगरिंग और हाथ-हिलाने की व्यवस्था (मानक इनपुट और मानक आउटपुट को पुनर्निर्देशित करके)। सामान्य संसाधन फाइल-स्ट्रीम होंगे।

सी ++ WIN32 में:

    1. इनपुट फ़ाइल-स्ट्रीम की व्याख्या करना।
    2. एच/डब्ल्यू के साथ बातचीत।
    3. एच/डब्ल्यू से जानकारी इकट्ठा करना और इसे अपने आउटपुट फ़ाइल-स्ट्रीम में डालना।
    4. UI को परीक्षण पूर्ण करने का संकेत (पुनर्निर्देशित मानक आउटपुट के माध्यम से)।

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

0
जोड़ा