Fichier source trop grandRésolu

Question

Bonjour à tous,
Je travaille actuellement sur un module d'environ 3200 lignes (dont 300 pour des déclarations) et qui grandit chaque jour, et Visual Studio commence tout doucement à ramer (il me faut parfois 5 secondes pour valider ma dernière ligne de code). 
J'imagine que c'est parce qu'à chaque modification, il vérifie la syntaxe et l'indentation de tout le reste.
Y aurait-il moyen de lui dire de ne pas vérifier le code qui est dans une région "collapsée" par exemple ? 
Ou bien de carrément retirer la gestion d'erreur en temps réel et devoir appuyer sur une touche pour faire une vérification ?

Merci !
__________________________
Julien.

lilo44 · Accepted Answer

pour la gestion des erreurs , c'est dans OUTILS > OPTIONS ...

verifier la syntaxe

lilo44 · Answer

Faut dire aussi que Vb, c'est bien pour faire joujou et faire des petits trucs sympas.


Quand on commence a taper dans des trucs enormes, ca devient quand meme vite limité ..... C'est pas pour rien que les gros logiciel sont pas en VB du reste ^^ Enfin, ca reste mon avis.

Pourquoi vous divisez pas un peu tout ca ? surtout que si c'est un module, ca ne pose pas de probleme de faire un deuxime module non ?

cs_casy · Answer

3200 lignes dont 300 de déclarations.

La première chose que j'aurais à dire, c'est que ça manque d'optimisation, d'organisation et de réflection tout ça.

J'ai été déjà ammené à faire de tres tres gros projets (certe pas avec VB2005 mais VB5) je n'ai jamais eu de problèmes de ralentissement à la saisie de code. 
Je pense que je n'ai jamais eu de fichier de 3200 lignes de codes, par contre plus du 50 fichiers pour un seul projet, oui.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

Julien237 · Answer

Merci !
(On peut se tutoyer si ça ne te dérange pas ?)
Pourquoi ne pas diviser le fichier ? > Parce que je me suis trompé en disant module, il s'agit d'une classe.
Nickel pour la vérification d'erreurs merci !

__________________________
Julien.

cs_DARKSIDIOUS · Answer

lilo44 : le problème ne vient pas que vb soit lent ou pas, mais du fait que Visual Studio soit lent sur des grands fichiers !

Perso, je trouve que vb (je parle de vb6 et non de vb.net) est un excellent compromis entre rapidité d'exécution et rapidité de développement.

Il existe quand même beaucoup de logiciels professionnels développés en vb.
Certes, si on veux faire du développement d'un logiciel très complexe ou des traitements qui demandent beaucoup de calculs, il vaut mieux utiliser un langage plus rapide (C++ et non C++.net !), mais dans la majorité des cas, vb suffit amplement (perso, je développe des logiciels en vb et en java, et bien que vb6 date (98 !), il est encore largement suffisant pour ce que je fait, et je n'utilise java que pour des projets spécifiques). Quant à l'utilisation de C++, j'en vois vraiment pas l'intérêt, si ce n'est perdre beaucoup de temps de développement (beaucoup plus de risques à développer en C++ qu'en vb niveau mémoire par exemple) pour au final une rapidité d'exécution qui dépend bien plus de l'algorithme utilisé que du langage lui-même !

Voilà c'était juste mon coup de gueule face à ta remarque sur vb.

Julien237 · Answer

En fait Casy, le projet est un peu "spécial", il s'agit d'adapter un classeur de calcul excel en code (notamment pour pouvoir faire plusieurs instances de chaque feuilles, des optimisations etc...), et je dois donc déclarer une classe "Tableau" par tableau contenu dans le classeur (ce qui explique mes 300 déclarations). 
(Je définis une tableau comme étant un ensemble de cellules contigues ayant le même type de formules, i.e. des cellules étendues avec la petite croix dans excel )
Et la classe de 3200 lignes en question est en fait une des feuilles totalisantes du classeur.
Je ne pense pas pouvoir faire plus organisé que ce que je fais, j'ai réfléchi longtemps à la manière dont j'allais m'y prendre et jusqu'ici, à part ce problème, ca me réussi plutot bien. Maintenant si tu as une meilleure idée n'hésite pas à me la proposer !
__________________________
Julien.

jmfmarques · Answer

Bonjour,

Moi j'arrive avec un truc bête (comme d'hab ...)

Le plupart des applications windows (et VB est dans ce cas) gardent en mémoire les modifications successives, pour pouvoir "revenir en arrière" à la demande, jusqu'à un enregistrement du fichier.

Il est pour moi clair qu'avec de trop longs fichoers et de nombreuses modifications sans sauvegarde, Windows va assez vite passer en zone de swap (et ce d'autant plus vite que d'autres applications seraient elle-même en train de manger leur part du gâteau).

Conseils, donc :

1) Evite d'avoir un trop grand nombre de processus en cours quand tu développes.
2) fais des sauvegardes plus fréquentes, de sorte à libérer le tampon des "retours en arrière"

lilo44 · Answer

julien > de rien

Dark > pas de polémiques de toute facon. Il s'agit juste de mon humble avis.
C'est pas une question de rapidité, c'est que VB est un truc "très" assisté et que fatalement, on perd un peu en marge de manoeuvre.
Dans la plupart des cas, et c'est ce que je disais plus haut, vb suffit normalement mais quand on commence a faire des trucs plus violent, on ne peut pas tout faire sous vb et, comme tu le disais, ca deviens difficile puisque VB a du mal a tout gerer.

Enfin, pour la question de rapidité d execution, je serais pas aussi catégorique..

Imagine des gros logiciels (pas d exemple la) codé en VB, je suis sur que la vitesse d execution serait loin d etre la meme chose. Les gros trucs doivent etre précis et VB est bien trop permissif et on perd forcement en performance mais c'est tellement leger sur les logiciels de taille moyenne que c'est invisible a l utilisation.

cs_DARKSIDIOUS · Answer

Non non, un code vb qui est bien pensé (donc auquel on réfléchit AVANT de coder, et non l'inverse comme c'est malheureusement souvent le cas chez les développeurs vb) peut rivaliser avec bon nombre de langages.

Perso, je trouve qu'il vaut mieux faire un bon algorithme optimisé en vb que faire un algorithme à ch*** en ASM. 

Vb n'est pas aussi rapide que le C/C++, ca c'est sûr, mais si tu utilise les API Windows et si tu te fait quelques librairies C pour les calculs demandant le plus de travail, je reste convaincu que faire un logiciel en vb est plus rentable que le même logiciel codé entièrement en C/C++ : tu y gagne beaucoup en rapidité de codage (et ce n'est rien comparé à java, qui malheureusement est très lourd à l'éxécution, ou sûrement à .net que je ne connais pas, mais qui doit être tout aussi lourd au vu des quelques tests que j'avais fait avec), et niveau exécution, tu n'as pas d'énorme différence perceptibles (ce n'est là aussi que mon humble avis). Mais je parle là de projets professionnels bien construits bien entendu avec une architecture logicielle réfléchie à l'avance, si les programmeurs codent avec les pieds, ils auront certainement plus tendance à mal coder avec vb qu'avec C/C++ qui demande plus de rigueur.

Le vb a si mauvaise réputation à cause de l'image des débutants qui codent avec je pense, niveau rapidité, il est loin d'être aussi lent que tout le monde le dit ! C'est comme le java : tout le monde le trouve très lent, et très lourd, mais au final, en codant bien, il n'est pas si lent que cà (par contre, niveau lourdeur, je n'ai pas encore trouvé les astuces pour le rendre plus léger !). Y'a qu'à voir la réputation qu'à vb à ma fac : tout le monde dit que vb c'est de la m****, et pourtant ils programment en java ! (pas tous, mais de nombreux étudiants).

Bref, depuis les longues annés que j'ai développé en vb (version 6 toujours, pas .net !!!), je n'ai pas encore trouvé un langage avec un aussi bon rapport vitesse de développement/rapidité d'exécution (faudrait que j'essaye le Delphi un de ces jours d'ailleurs, il paraît qu'il est mieux que vb).

jmfmarques · Answer

Je viens appuyer ce qu'a exprimé DarkSidious et qui est on ne peut plus vrai...
Cà l'est encore plus si l'on sait se passer de nombreuses "bébelles" que l'on peut remplacer plus efficacement (pas plus légèrement en code écrit, mais plus rapide à l'exécution) par des fonctions de l'API de Windows (je pense, entre autres petites et grandes choses, au CommonDialog, DTPicker, et tutti quanti...)

cs_casy · Answer

Entierement d'accord avec Dark en ce qui concerne VB6.

C'est certain que un logiciel codé merdiquement en VB6 (et c'est certainement le plus pratique pour cela) sera plus lent que le même logiciel codé correctement, mais l'inverse est aussi vrai.

Et si on exclue tout ce qui est calculs lourds et longs nécessitant énormement de ressources systèmes, un logiciel VB6 optimisé rivalise sans problème avec le même logiciel optimisé en C.

Concernant le VB.NET, si on fait la comparaison bien évidement avec ce qui est comparable, c'est à dire un autre langage .Net (C, C#, ...)la différence est infinitésimale puisque quelque soit le langage utiliser pour le code, le langage executé sera l'IL. Et l'IL résultant de chacun des langages sera certainement à plus de 99.9% identique.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

Fichier source trop grand

11 réponses

Votre réponse

Discussions similaires