Prestazioni: C# 3.5 o VB 9 ?

Question

Ciao a tutti!

Ho un progettone di contabiltà in VB9 fw 3.5 SP1 con tecnologia mista Win-Form / WPF.

Premesso che sono interessato a tutto ciò che può servire a migliorare le prestazioni del programma mi sto domandando se ha senso migrare tutto in C# 3.5. E' vero quel che ho sentito che il compilatore lavora meglio con C# e produce file più 'performanti'?

Grazie!

Pileggi

Answer 1

Ciao pileggi,

Ciao a tutti!

Ho un progettone di contabiltà in VB9 fw 3.5 SP1 con tecnologia mista Win-Form / WPF.

Premesso che sono interessato a tutto ciò che può servire a migliorare le prestazioni del programma mi sto domandando se ha senso migrare tutto in C# 3.5. E' vero quel che ho sentito che il compilatore lavora meglio con C# e produce file più 'performanti'?

Grazie!

Pileggi

in questo thread si parla delle differenze trà vb.net e c# , spero possa darti un'idea.

http://social.msdn.microsoft.com/Forums/it-IT/visualcsharpit/thread/1934b5dc-afba-4dd8-95f0-2a6706c136c0

 

Ciao

---

Carmelo La Monica  http://community.visual-basic.it/carmelolamonica/

Answer 2

quel che hai sentito è una bufala. Lavora con quel che preferisci.

La cosidetta 'zeppa' di Visual Basic sta solo in ciò che di 'vecchio VB6 like' si continua a usare (e basta un minimo di disciplina per non farlo).

Anzi, è talvolta meglio usare qualcosa di VisualBasic, o di My, e si ottengono maggiori preformance rispetto alla stessa cosa (più o meno introvabile) in C#.

Ma alla fine fine, per la maggior parte del codice che viene prodotto, per la stragrandissima maggioranza, non c'è alcuna differenza.

---

please, mark this as answer if it is THE answer
----------------
Diego Cattaruzza
Microsoft MVP - Visual Basic: Development
blog: http://community.visual-basic.it/Diego
web site: http://www.visual-basic.it

Answer 3

Come dice anche Diego, lavora con ciò che preferisci e che ti fa avere una migliore produttività.
Parlare di performance e basta è una cosa inutile. Credo sia necessario sempre contastualizzare il discorso. Si parla di performance nell'accesso ai dati o la responsività della UI? O di altro?
Personalmente, ad esempio, su un programma che tendenzialmente potrebbe crescere e avere una stima di vita molto lunga, preferisco avere un pizzico di performance in meno (stiamo parlando di un pizzico) e avere migliore manutenibilità o scalabilità.
Se il tuo utente medio del programma di contabilità aspetta 1/10 di secondo in più, nella stragrande maggioranza dei casi non succede nulla (poi dipende anche dal fatto che la performance non sia un requisito ben determnato). Viceversa se ogni volta che devi adattare il tuo software ad eventuali modifiche ci metti tanto, allora il discorso cambia e il cliente potrebbe anche non essere daccordo.
Ovviamente se stai realizzando un software real-time il discorso cambia radicalmente, ma non mi sembra essere il tuo caso.
E' un mio parere e come tale, discutibile.

Answer 4

Ciao Massimo,

You wrote on 09/08/2011 :

E' un mio parere e come tale, discutibile.

ma anche ampiamente condivisibile.

.m

---

Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ http://milestone.topics.it
whynot [ at ] topics [ dot ] it

Answer 5

quel che hai sentito è una bufala. Lavora con quel che preferisci.

La cosidetta 'zeppa' di Visual Basic sta solo in ciò che di 'vecchio VB6 like' si continua a usare (e basta un minimo di disciplina per non farlo).

Anzi, è talvolta meglio usare qualcosa di VisualBasic, o di My, e si ottengono maggiori preformance rispetto alla stessa cosa (più o meno introvabile) in C#.

Ma alla fine fine, per la maggior parte del codice che viene prodotto, per la stragrandissima maggioranza, non c'è alcuna differenza.

---

please, mark this as answer if it is THE answer
----------------
Diego Cattaruzza
Microsoft MVP - Visual Basic: Development
blog: http://community.visual-basic.it/Diego
web site: http://www.visual-basic.it

Grazie tante Diego!

Mi rimane un piccolo dubbio a proposito del codice 'vecchio VB6 like'. Anch'io, come te, vengo da VB6. Tempo fa ho letto su VB Tips & Tricks un tuo articolo in cui consigli di non usare più le funzioni di VB6. Non so, potrei aver capito male ma tu intendevi cose tipo non usare Len(miaStringa) e usare invece miaStringa.Lenght, giusto? Se così, io ho seguito il tuo consiglio, ma qualcuno mi ha detto che al contrario il compilatore VB interpreta meglio le istruzioni scritte con i membri del namespace VisualBasic. Praticamente io ho continuato a seguire il tuo consiglio, l'unica eccezzione l'ho fatta per le funzioni di conversione CDbl(miaStringa) in quanto trovo la sintassi VB molto comoda, immedata e univoca, invece con gli altri metodi di .NET è difficile capire cosa è meglio usare. Penso che in termini di prestazioni non ci sia una grossa differenza, giusto? Potresti darmi ragguagli rispetto all'importanza di non continuare a usare codice 'VB6 like'?

Pileggi

Answer 6

Quando utilizzi una funzione VB6 LIKE (tipo la Len() che hai citato), di solito, il compilatore (che non è lo stesso di C#, ma è specifico per VB e, quindi non è vero che digerisce megli C#) la sostituisce con la chiamata ad un metodo di una classe che si trova nel namespace Microsoft.VisualBasic.
Te ne puoi rendere conto utilizzando un decompilatore come Reflector. Ad esempio, se scriviamo:

Dim stringa = "pippo"
Dim lunghezza = Len(stringa)

diventa:

Dim stringa As String = "pippo"
Dim lunghezza As Integer = Strings.Len(stringa)

Come vedi c'è l'utilizzo del metodo statico (Shared) Len della classe Strings (contenuta in Microsoft.VisualBasic):

Public Shared Function Len(ByVal Expression As String) As Integer
   If (Expression Is Nothing) Then
       Return 0
   End If
   Return Expression.Length
End Function

Come vedi, alla fine viene richiamata la proprietà Length della classe String.
Il vantaggio, in questo caso è che puoi scrivere Len(Nothing) mentre non puoi invocare Length su una istanza Nothing di String.

Answer 7

Quando utilizzi una funzione VB6 LIKE (tipo la Len() che hai citato), di solito, il compilatore (che non è lo stesso di C#, ma è specifico per VB e, quindi non è vero che digerisce megli C#) la sostituisce con la chiamata ad un metodo di una classe che si trova nel namespace Microsoft.VisualBasic.
Te ne puoi rendere conto utilizzando un decompilatore come Reflector. Ad esempio, se scriviamo:

Dim stringa = "pippo"
Dim lunghezza = Len(stringa)

diventa:

Dim stringa As String = "pippo"
Dim lunghezza As Integer = Strings.Len(stringa)

Come vedi c'è l'utilizzo del metodo statico (Shared) Len della classe Strings (contenuta in Microsoft.VisualBasic):

Public Shared Function Len(ByVal Expression As String) As Integer
  If (Expression Is Nothing) Then
    Return 0
  End If
  Return Expression.Length
End Function

Come vedi, alla fine viene richiamata la proprietà Length della classe String.
Il vantaggio, in questo caso è che puoi scrivere Len(Nothing) mentre non puoi invocare Length su una istanza Nothing di String.

Grazie Massimo!

Answer 8

alcune 'funzioni' (ex VB6) sono state purtroppo implementate nel 'core' della libreria VisualBasic. Di conseguenza sono quasi tutte più rapide degli analoghi metodi di tipo cui dovrebbero invece riferirsi.

Non solo. Presentano anche altri vantaggi, tipo la gestione di istanze nulle o la capacità di gestire parametri non tipizzati.

 Talvolta (come proprio nell'esempio della funzione Len di cui leggi nella risposta di Massimo), sono solo dei wrapper dei membri di tipo (e allora sarebbero più lente).

I veri vantaggi di performance sono apprezzabili sono in occasione di cicli di centinaia di migliaia di esecuzioni dello stesso passo. E sono apprezzabili nell'ordine di qualche decimo di secondo. Quindi è del tutto ininfluente usare le 'funzioni di linguaggio' oppure i 'metodi di tipo'.

Io 'predico' di non usare queste funzioni (che spero prima o poi si decidano a togliere, anche a costo di rompere compatibilità - e secondo me è nella logica delle cose che spariscano) perché 'coltivo' il concetto di oggetto e suo membro. Tutto qua. E' una questione di logica semantica, non di efficienza.

L'importanza di non usare 'vecchie funzioni di linguaggio', e di usare i 'metodi di tipo' sta nel fatto mentale di 'pensare sempre a oggetti' e non 'un po' a oggetti e un po'no'.

---

please, mark this as answer if it is THE answer
----------------
Diego Cattaruzza
Microsoft MVP - Visual Basic: Development
blog: http://community.visual-basic.it/Diego
web site: http://www.visual-basic.it

Answer 9

DiegoCattaruzza [MVP] wrote:

alcune 'funzioni' (ex VB6) sono state purtroppo implementate nel 'core' della libreria VisualBasic. Di conseguenza sono quasi tutte più rapide degli analoghi metodi di tipo cui dovrebbero invece riferirsi.

Solo una precisazione..
sono "rapide" da scriversi ma ovviamente, trattandosi di una libreria, comporta una microscopica penalizzazione in performance oltre ad un leggerissimo carico supplementare in memoria dovuto al caricamento della libreria stessa.

Un dev vb dovrebbe cominciare a mio avviso cominciare da questi punti:
1. usare sempre e comunque  Option Strict
2. non usare mai la libreria visualbasic
2a. permette di capire meglio cosa si sta utilizzando
2b. permette di rendere più leggibile il codice a chi usa altri linguaggi managed (non solo c#)

my 2 cents

---

Raffaele Rialdi  http://www.iamraf.net
Weblog: http://blogs.ugidotnet.org/raffaele
Microsoft MVP profile https://mvp.support.microsoft.com/profile/raffaele
UGIdotNET - http://www.ugidotnet.org/

---

Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele