Baie stadig stel keer op Visual Studio 2005

https://stackoverflow.com/questions/55517

09-06-2019
|

Vra

Ons is steeds baie stadig stel tye, wat kan opwaarts neem van 20+ minute op dual core 2GHz, 2G Ram masjiene.

Baie van hierdie is as gevolg van die grootte van ons oplossing wat gegroei het tot 70+ projekte, sowel as die VERSE wat is'n bottel nek in homself wanneer jy het'n baie van die lêers.(die uitruiling van uit VERSE is nie'n opsie ongelukkig, so ek wil dit nie om te daal in'n VSS bash)

Ons is op soek na die samesmelting van projekte.Ons is ook op soek na die feit dat verskeie oplossings te bereik groter skeiding van kommer en vinniger tye saam te stel vir elke element van die aansoek.Dit kan ek sien, sal'n DLL hel as ons probeer om dinge te hou in synch.

Ek is geïnteresseerd om te weet hoe die ander spanne het gehandel oor hierdie skalering kwessie, wat doen jy wanneer jou kode basis bereik'n kritieke massa wat jy mors die helfte van die dag kyk na die status bar lewer stel boodskappe.

UPDATE Ek het nagelaat om te noem hierdie is'n C# oplossing.Dankie vir al die C++ voorstelle, maar dit was'n paar jaar sedert ek het om te bekommer oor die kop.

EDIT:

Lekker voorstelle wat gehelp het om so ver (nie te sê daar is nie ander mooi voorstelle hieronder, net wat gehelp het)

Nuwe 3GHz laptop - die krag van die verlore benutting werk wonders wanneer whinging te bestuur
Skakel Anti-Virus tydens stel
'Ontkoppel" van VERSE (eintlik die netwerk) tydens stel - ek kan kry om ons te verwyder VS-VERSE integrasie geheel en al en vashou aan die gebruik van die VERSE UI

Het nog nie die rip-gesnuif deur middel van'n stel, maar elke bietjie help.

Orion het noem in'n kommentaar wat generiese medisyne kan'n speel ook.Van my toetse was daar nie blyk te wees'n minimale prestasie getref, maar nie hoog genoeg is om te seker - stel tye kan word strydig as gevolg skyf aktiwiteit.As gevolg van die tyd beperkings, my toetse het nie sluit as baie Generiese, of soveel kode, as sou verskyn in lewende stelsel, sodat dit kan ophoop.Ek sou nie vermy die gebruik van generiese waar hulle is veronderstel om gebruik te word, net vir die stel tyd prestasie

OPLOSSING

Ons is die toets van die praktyk van die bou van nuwe gebiede van die aansoek in nuwe oplossings, die invoer in die jongste dlls as wat nodig is, hulle die integrasie van hulle in die groter oplossing wanneer ons is gelukkig met hulle.

Ons kan dit ook doen hulle dieselfde aan bestaande kode deur die skep van tydelike oplossings wat net omsluit die gebiede wat ons nodig het om te werk op, en gooi hulle weg na die herintegrasie van die kode.Ons nodig het om te weeg op die tyd wat dit sal neem om te herintegreer hierdie kode teen die tyd wat ons kry deur nie met Rip Van Winkle soos ervarings met'n vinnige recompiling tydens die ontwikkeling.

Oplossing

Die Chromium.org span gelys verskeie opsies vir versnel die opbou (op hierdie punt oor half-pad af die bladsy):

In dalende volgorde van speedup:


Installeer Microsoft hotfix 935225 .

Installeer Microsoft hotfix 947315 .

Gebruik 'n ware multicore verwerker (dws 'n Intel Core Duo 2;. Nie 'n Pentium 4 HT).

Gebruik 3 parallel bou. In Visual Studio 2005, sal jy die opsie in te vind Tools> Options ...> Projekte en Solutions> Bou en hardloop> maksimum aantal parallelle projek bou .

Skakel jou anti-virus sagteware vir .ilk, Pdb, cc, .H lêers en kyk net vir virusse op verander . Skakel die skandering van die gids waar jou bronne woon. Moenie iets dom doen nie.

Store en bou die Chroom-kode op 'n tweede hardeskyf. Dit sal nie regtig die bespoediging van die bou, maar ten minste sal jou rekenaar reageer bly wanneer jy gclient sync of 'n gebou te doen.

Defragmenteer jou hardeskyf gereeld.

Skakel virtuele geheue.

Ander wenke

Ons het byna 100 projekte in een oplossing en 'n dev bou tyd van net sekondes:)

Vir plaaslike ontwikkeling bou ons 'n Visual Studio Addin dat Project references om DLL references verander en ontlaai die ongewenste projekte geskep (en 'n opsie om hulle terug natuurlik oorskakel).

Bou ons hele oplossing weer
Laai die projekte wat ons nie tans besig om op en verander al projek verwysings na DLL verwysings.
Voor check-in verandering alle verwysings terug vanaf DLL om verwysings te projekteer.

Ons bou nou net sekondes neem wanneer ons is besig om op slegs 'n paar projekte op 'n slag. Ons kan ook nog ontfout die bykomende projekte as dit koppel aan die debug DLLs. Die instrument duur gewoonlik 10-30 sekondes om 'n groot aantal veranderinge aan te bring, maar jy hoef nie om dit te doen wat dikwels.

Update Mei 2015

Die transaksie wat ek gemaak het (in kommentaar hieronder), was dat ek die prop sou loslaat open source as dit kry genoeg belangstelling. 4 jaar later het dit net 44 stemme (en Visual Studio het nou twee daaropvolgende weergawes), so dit is op die oomblik 'n lae-prioriteit projek.

Ek het 'n soortgelyke probleem op 'n oplossing met 21 projekte en 1/2 miljoen LOC. Die grootste verskil is steeds vinniger hardeskyf. Van die prestasie te monitor die Gem. Skyf Queue 'sou aansienlik opspring op die laptop wat die hardeskyf is die bottelnek.

Hier is 'n paar data vir totale herbou keer ...

1) Laptop, Core 2 Duo 2GHz, 5400 RPM Drive (nie seker van die kas. Was standaard Dell Inspiron).

Herbou Time = 112 sekondes.

2) Desktop (standaard kwessie), Core 2 Duo 2,3, enkele 7200RPM Drive 8MB Cache.

Herbou Time = 72 sekondes.

3) Desktop Core 2 Duo 3Ghz, enkele 10000 RPM WD Raptor

Herbou Time = 39 sekondes.

Die 10,000 RPM ry kan nie onderskat word nie. Bou waar aansienlik vinniger plus al die ander soos die vertoon van dokumentasie, met behulp van lêer ontdekkingsreisiger is merkbare vinniger. Dit was 'n groot produktiwiteit hupstoot deur die bespoediging van die kode-opbou run siklus.

Gegee wat maatskappye spandeer op ontwikkelaar salarisse is dit stapelgek hoeveel hulle kan mors koop toe te rus vir hulle met dieselfde rekenaars as die ontvangsdame gebruik.

Vir C # NET bou, kan jy gebruik . NET Demon . Dit is 'n produk wat oor die Visual Studio bou proses neem om dit vinniger te maak.

Dit word gedoen deur die ontleding van die veranderinge wat jy gemaak het, en bou net die projek wat jy eintlik verander, asook ander projekte wat eintlik staatgemaak op die veranderinge wat jy gemaak. Dit beteken dat as jy net interne kode verander, net een projek moet bou.

Skakel jou antivirus. Dit voeg ouderdomme om die kompilering.

Gebruik versprei samestelling. Xoreax IncrediBuild kan sny samestelling tyd af te paar minute.

Ek het dit gebruik op 'n groot C \ C ++ oplossing wat gewoonlik 5-6 ure op te stel. IncrediBuild gehelp om hierdie tyd te verminder tot 15 minute.

Instruksies vir die vermindering van jou Visual Studio stel tyd om 'n paar sekondes

Visual Studio is ongelukkig nie slim genoeg om 'n gemeente se koppelvlak veranderinge van onbelangrike kode liggaamsveranderinge onderskei. Hierdie feit, wanneer dit gekombineer met 'n groot verweef oplossings, kan soms skep 'n perfekte storm van ongewenste 'full-bou "byna elke keer as jy 'n enkele reël van die kode te verander.

'n strategie om dit te oorkom is om te skakel die outomatiese verwysing-boom bou. Om dit te doen, gebruik die "Configuration Bestuurder (Bou / konfigurasiebestuurder ... dan in die Active oplossing opset dropdown, kies 'Nuwe') om 'n nuwe te bou opset genoem 'ManualCompile' dat afskrifte van die Debug opset, skep, maar doen nie check die boks 'Skep nuwe projek konfigurasies. In hierdie nuwe bou opset, aktiveer elke projek so dat nie een van hulle outomaties sal bou. Behalwe hierdie opset deur slaan 'Close'. Hierdie nuwe bou opset bygevoeg om jou oplossing lêer.

Jy kan via die bou opset dropdown oorskakel van een bou opset na 'n ander aan die bokant van jou IDE skerm (die een wat gewoonlik toon óf 'Debug "of" Release "). Effektief hierdie nuwe ManualCompile bou opset sal lewer nutteloos die Bou kieslys opsies vir: 'Bou Oplossing "of" Herbou Oplossing. Dus, wanneer jy in die ManualCompile af, jy moet met die hand elke projek wat jy verander, wat kan gedoen word deur regs te klik op elke geaffekteerde projek in die oplossing Explorer, en dan kies 'Bou' of 'herbou' te bou. Jy moet sien dat jou algehele Stel keer nou sal 'n paar sekondes.

Vir hierdie strategie is om te werk, is dit nodig vir hierdie weergawe gevind in die AssemblyInfo en GlobalAssemblyInfo lêers statiese op masjien die ontwikkelaar se te bly (nie tydens vrylating bou natuurlik), en dat jy nie jou DLLs teken.

'n potensiële risiko van die gebruik van hierdie strategie ManualCompile is dat die ontwikkelaar kan vergeet om vereiste projekte op te stel, en wanneer hulle die debugger begin, kry hulle onverwagte resultate (nie debugger heg, lêers nie gevind nie, ens). Om dit te voorkom, is dit waarskynlik die beste om die "Debug" bou opset gebruik om 'n groter kodering poging stel, en gebruik net die ManualCompile bou opset tydens eenheid toets of vir die maak van vinnige veranderinge wat van beperkte omvang.

As dit C of C ++, en wat jy nie gebruik compileerde kop, moet jy wees.

Ons het 'n 80 + projekte in ons belangrikste oplossing wat 4 tot 6 minute geneem om te bou, afhangende van watter soort masjien 'n ontwikkelaar is besig. Ons is van mening dat om te lank wees:. Vir elke enkele toets dit regtig vreet jou fte

So hoe om vinniger te bou keer? As jy lyk reeds weet dit is die aantal projekte wat werklik die buildtime seermaak. Natuurlik het ons nie wil om ontslae te raak van al ons projekte en eenvoudig gooi al bronkodelêers in een. Maar ons het 'n paar projekte wat ons nogtans kan kombineer: Soos elke "Repository projek" in die oplossing van sy eie unittest projek het, het ons net gekombineer al die unittest projekte in een globale-unittest projek. Wat afgekap die aantal projekte met sowat 12 projekte en een of ander manier gered 40% van die tyd om die hele oplossing te bou.

Ons dink oor 'n ander oplossing though.

Het jy ook probeer om te installeer 'n nuwe (tweede) oplossing met 'n nuwe projek? Hierdie tweede oplossing moet eenvoudig inkorporeer al die lêers met behulp van oplossing dopgehou. Omdat jy verbaas wees om te die opbou tyd van die nuwe oplossing-met-net-een-projek sien mag wees.

Maar, in samewerking met twee verskillende oplossings sal 'n paar versigtig ag te neem. Ontwikkelaars sou geneig wees om werklik -work- in die tweede oplossing en heeltemal verwaarloos die eerste. As die eerste oplossing met die 70 + projekte die oplossing wat sorg vir jou voorwerp-hiërargie neem sal wees, moet dit die oplossing waar jou buildserver al jou unittests moet hardloop nie. So die bediener vir deurlopende integrasie moet die eerste projek / oplossing wees. Jy moet jou voorwerp-hiërargie in stand te hou, reg.

Die tweede oplossing met net een projek (wat mucho vinniger sal bou) sal as die projek waar toetsing en ontfouting sal gedoen word deur alle ontwikkelaars wees. Jy moet sorg vir hulle te kyk na die buildserver al! As daar iets breek, moet dit vas.

Maak seker dat jou verwysings is Projek verwysings, en nie direk na die DLLs in die biblioteek uitset dopgehou.

Ook, het hierdie stel om nie plaaslik kopieer, behalwe waar dit absoluut noodsaaklik is (Die meester EXE projek).

Ek gepos hierdie reaksie oorspronklik hier: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 Jy kan baie ander nuttige wenke vind op daardie bladsy.

As jy met behulp van Visual Studio 2008, kan jy stel met behulp van die / LP vlag aan 'n enkele projek in parallel te bou. Ek het gelees dat dit ook 'n ongedokumenteerde funksie in Visual Studio 2005, maar het myself nog nooit probeer.

Jy kan verskeie projekte in parallel te bou met behulp van die / M vlag, maar dit is gewoonlik reeds ingestel om die aantal beskikbare kerne op die masjien, maar dit is net van toepassing op VC ++ ek glo.

Ek sien hierdie vraag is eeue oud, maar die onderwerp is nog van belang vandag. Dieselfde probleem gebyt my die afgelope tyd, en die twee dinge wat bou prestasie verbeter die meeste was (1) gebruik 'n toegewyde (en vinnig) skyf vir die opstel en (2) gebruik dieselfde outputfolder vir alle projekte, en stel CopyLocal om Vals op projek verwysings.

Sommige bykomende hulpbronne:

Sommige analise gereedskap:

tools> Options-> VC ++ projek instellings -> Bou Timing = Ja sal vertel jou tyd te bou vir elke vcproj.

Voeg /Bt oorskakel na samesteller command line om te sien hoeveel elke CPP lêer het

Gebruik /showIncludes te vang geneste sluit (header lêers wat ander header lêers insluit), en sien wat lêers baie IO kan bespaar deur die gebruik vorentoe verklarings.

Dit sal jou help om samesteller prestasie te optimaliseer deur die uitskakeling van afhanklikhede en prestasie varke.

Voor die besteding van geld te belê in 'n vinniger hardeskywe, probeer die bou van jou projek geheel en al op 'n RAM-skyf (as jy het die geheue te spaar). Jy kan verskeie gratis RAM-skyf bestuurders op die netto vind. Jy sal 'n fisiese ry nie vind, insluitend SSDs, wat vinniger as 'n RAM-skyf is.

In my geval, 'n projek wat 5 minute geneem om te bou op 'n 6-Core i7 op 'n 7200 RPM SATA drive met Incredibuild verminder deur slegs sowat 15 sekondes met behulp van 'n RAM-skyf. Met inagneming van die behoefte om recopy om permanente stoor en die potensiaal vir verlore werk, 15 sekondes is nie genoeg aansporing om 'n RAM-skyf en waarskynlik nie veel aansporing gebruik om 'n paar honderd dollar te spandeer op 'n hoë-RPM of SSD ry.

Die klein wins kan daarop dui dat die opbou was CPU gebind of dat Windows lêer caching was nogal effektief, maar aangesien beide toetse is gedoen uit 'n toestand waar die lêers nie is die kas, ek leun swaar teen-CPU gebind saamstel.

Na gelang van die werklike kode wat jy die opstel van jou kilometers kan wissel -. So moet asseblief nie huiwer om te toets

Hoe groot is jou bou gids na doen 'n volledige bou? As jy vashou aan die standaard setup dan sal elke vergadering wat jy bou al van die DLLs van sy afhanklikes en afhanklikes sy afhanklikhede 'ens om sy bin gids kopieer. In my vorige werk by die werk met 'n oplossing van ~ 40 projekte my kollegas ontdek dat by verre die duurste deel van die bou proses is oor en oor die kopiëring van hierdie gemeentes, en dat 'n mens bou GB van kopieë van dieselfde DLLs oor kan genereer en oor weer.

Hier is 'n paar nuttige advies van Patrick Smacchia, skrywer van NDepend, oor wat hy glo moet en nie moet wees afsonderlike gemeentes:

http: // codebetter com / patricksmacchia / 2008/12/08 / advies-on-skeiding-kode-deur-net-gemeentes /

Daar is basies twee maniere waarop jy kan werk om hierdie, en albei het nadele. Een daarvan is om die aantal gemeentes, wat natuurlik 'n baie werk te verminder. Nog is om jou bou dopgehou te herstruktureer sodat al jou bin dopgehou word gekonsolideer en projekte nie DLLs hul afhanklikes 'n afskrif - hulle hoef nie, want hulle is almal in dieselfde gids reeds. Dit verminder drasties die aantal lêers geskep en kopieer tydens 'n bou, maar dit kan moeilik wees om op te rig en kan laat jou met 'n paar probleme trek uit slegs die vereiste deur 'n spesifieke program vir verpakking DLLs.

Miskien neem 'n paar algemene funksies en maak 'n paar biblioteke, die manier dieselfde bronne is nie oor en oor weer saamgestel vir verskeie projekte.

As jy bekommerd is oor die verskillende weergawes van DLLs om deurmekaar is, gebruik statiese biblioteke.

Skakel VSS integrasie. Jy mag nie 'n keuse nie in gebruik nie, maar DLLs kry "per ongeluk" herdoop al die tyd ...

En beslis jou pre-saamgestel kop instellings te keur. gids Bruce Dawson se is 'n bietjie oud, maar nog steeds baie goeie - check dit uit: http://www.cygnus-software.com/papers/precompiledheaders.html

Ek het'n projek wat 120 of meer ekse, libs en dlls en neem'n aansienlike tyd om te bou.Ek gebruik'n boom van die joernaal lêers wat oproep maak lêers van die een meester joernaal lêer.Ek het probleme gehad met die vreemde dinge van inkrementele (of was dit temperament) headers in die verlede so ek vermy hulle nou.Ek doen'n volledige bou selde, en gewoonlik laat dit aan die einde van die dag, terwyl ek gaan vir'n loop vir'n uur (so ek kan net dink wat dit neem sowat'n halfuur).So ek verstaan nie hoekom dit is onwerkbaar vir die werk en toets.

Vir die werk en toetsing ek het'n ander stel van die joernaal lêers vir elke artikels (of module of biblioteek) wat ook al die ontfouting instellings in plek-maar dit nog steeds noem die dieselfde maak lêers.Ek kan skakel DEBUG op van af van tyd tot tyd en het ook besluit op die bou of maak of as ek wil om ook die bou van libs wat die module kan afhang van, en so aan.

Die batch file ook afskrifte van die voltooide lei in die (of'n paar) toets dopgehou.Afhangende van die instellings dit voltooi in'n paar sekondes tot'n minuut (eerder as om te sê die helfte van'n uur).

Ek gebruik'n ander IDE (Zeus) as ek wil om beheer te hê oor dinge soos .rc lêers, en eintlik verkies om saam te stel uit die opdrag lyn, selfs al het ek is met behulp van MS compliers.

Bly om te post'n voorbeeld van hierdie joernaal lêer as iemand belangstel.

afskakel lêerstelsel kruip op jou bron dopgehou (spesifiek die obj dopgehou as jy wil hê dat jou bron gesoek)

As dit is 'n web artikels, die opstel van die bondel te bou om waar te kan help, afhangende van die scenario.

<compilation defaultLanguage="c#" debug="true" batch="true" >

Jy kan 'n oorsig hier vind: http: // weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Jy kan ook wil om te kyk vir omsendbrief projek verwysings. Dit was 'n probleem vir my 'n keer.

Dit is:

Project A verwysings Projek B

Projek B verwysings Projek C

Project C verwysings Projek A

Een goedkoper alternatief vir Xoreax IB is die gebruik van wat ek noem uber-lêer bou. Dit is basies 'n Cpp lêer wat

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Toe die uber-eenhede in plaas van die individuele modules saam te stel nie. Ons het Stel tye van 10-15 minute af gesien om 1-2 minute. Jy kan hê om experiemnt met hoeveel #includes per uber lêer sin maak. Hang af van die projekte. ens Miskien sluit 10 lêers, miskien 20.

Jy betaal 'n koste so pasop:

Jy kan nie regs kliek 'n lêer en sê "stel ..." as jy die individuele CPP-lêers van die bou uitsluit en sluit net die uber CPP-lêers
Jy moet versigtig wees van statiese globale veranderlike konflikte te wees.
Wanneer jy 'n nuwe modules by te voeg, moet jy die uber lêers op datum te hou

Dit is soort van 'n pyn, maar vir 'n projek wat grootliks statiese in terme van nuwe modules, kan die aanvanklike pyn die moeite werd wees. Ek het gesien hierdie metode te klop IB in sommige gevalle.

As dit is 'n C ++ projek, dan moet jy wees met behulp van compileerde kop. Dit maak 'n groot verskil in Stel keer. Nie seker wat cl.exe regtig doen (met nie met behulp van compileerde kop), dit blyk te wees op soek na baie van STL kop in al die verkeerde plekke voordat hulle uiteindelik gaan na die regte plek. Dit voeg hele sekondes om elke enkele Cpp lêer opgestel. Nie seker of dit is 'n cl.exe fout, of 'n soort van STL probleem in VS2008.

As ons kyk na die masjien wat jy bou op, is dit optimaal ingestel?

Ons het net ons bou tyd vir ons grootste C ++ onderneming-skaal produk uit die 19 uur om 16 minute deur te verseker die reg SATA filter bestuurder is geïnstalleer.

Subtiele.

Daar is ongedokumenteerde / LP skakelaar in Visual Studio 2005, sien http://lahsiv.net/blog /? p = 40 , wat parallel samestelling op lêer basis eerder as basis projek in staat sal stel. Dit kan bespoedig die samestelling van die laaste projek, of, as jy 'n projek saam te stel.

By die keuse van 'n CPU: L1 kas grootte lyk na 'n groot impak op die samestelling tyd. Ook, dit is gewoonlik beter om 2 vinnige cores as 4 stadige kinders hê. Visual Studio nie baie effektief gebruik die ekstra cores. (Ek baseer dit op my ervaring met die C ++ vertaler, maar dit is waarskynlik ook waar vir die C # een.)

Ek is ook nou oortuig daar is 'n probleem met VS2008. Ek is dit wat uitgevoer word op 'n dual core Intel laptop met 3G Ram, met anti-virus afgeskakel. Die samestelling van die oplossing is dikwels baie gladde, maar as ek is debugging n daaropvolgende heropstel sal dikwels vertraag om 'n crawl. Dit is duidelik uit die deurlopende belangrikste skyf lig dat daar 'n skyf I / O bottelnek (jy kan dit hoor, ook). As ek die opbou en afsluit kanselleer VS die skyf aktiwiteit tot stilstand kom. Restart VS, herlaai die oplossing en dan weer op te bou, en dit is baie vinniger. Nou beskikbaar by die volgende keer

My gedagtes is dat dit 'n geheue blaai probleem - VS net loop uit van die geheue en die O / S begin bladsy uitruiling te probeer om plek te maak, maar VS eis meer as bladsy uitruiling kan lewer, so dit stadiger om 'n crawl. Ek kan nie dink aan enige ander verduideliking.

VS is beslis nie 'n RAD instrument, is dit?

Maak jou maatskappy gebeur Entrust gebruik vir hul PKI / Encryption oplossing deur 'n kans? Dit blyk dat ons met onpeilbaar bou prestasie vir 'n redelike groot webwerf gebou in C #, neem 7+ minute op 'n herbou-All.

My masjien is 'n i7-3770 met 16GB ram en 'n 512GB SSD, so prestasie moet nie gewees het so sleg nie. Ek het opgemerk my opbou keer was intens vinniger op 'n ouer sekondêre masjien bou dieselfde kodebasis. So ek afgevuur ProcMon op beide masjiene, geprofileerde die bou, en vergelyk met die resultate.

En kyk, die stadige-presterende masjien het 'n verskil - 'n verwysing na die Entrust.dll in die stacktrace. Die gebruik van hierdie nuutverworwe inligting, ek het voortgegaan om te soek StackOverflow en het gevind dat hierdie: MSBUILD (VS2010 ) baie stadig op sommige masjiene . Volgens die aanvaarde antwoord die probleem lê in die feit dat die Entrust hanteerder is die verwerking van die NET sertifikaat tjeks in plaas van die inheemse Microsoft hanteerder. TT is ook voorgestel dat Entrust v10 los hierdie probleem wat voorkom in Entrust 9.

Ek oomblik het dit verwyder en my opbou keer gedaal tot 24 sekondes . YYMV met die aantal projekte wat jy op die oomblik is die bou van en mag nie direk die skaal probleem wat jy is u navraag doen oor aan te spreek. Ek sal 'n verandering plaas om hierdie reaksie as ek 'n fix sonder kan verskaf wend om 'n verwydering van die sagteware.

Dit is seker daar is 'n probleem met VS2008. Want die enigste ding het ek gedoen dis om VS2008 installeer vir die opgradering van my projek wat geskep is met VS2005. Ek het nog net 2 projekte in my oplossing. Dit is nie groot. Samestelling met VS2005: 30 secondes Samestelling met VS2008: 5 minute

Nice voorstelle wat tot dusver gehelp (nie te sê daar is nie ander lekker voorstelle hieronder, as jy probleme het, raai ek lees dan, net wat ons gehelp het)

New 3Ghz laptop - die krag van verlore benutting werk wonders wanneer whinging te bestuur
Skakel Anti Virus tydens kompilering
'Afkoppelen' uit VSS (eintlik die netwerk) tydens kompilering - ek kan kry om VS-VSS integrasie heeltemal verwyder en vashou aan die gebruik van die VSS UI

Nog nie rip-gesnuif deur 'n Stel, maar elke bietjie help.

Ons is ook die toets van die praktyk van die bou van nuwe gebiede van die aansoek in nuwe oplossings, invoer in die jongste dlls soos vereis, hulle hulle integrasie in die groter oplossing as ons gelukkig is met hulle.

Ons kan ook doen hulle dieselfde aan bestaande kode deur die skep van tydelike oplossings wat net omsluit die gebiede wat ons nodig het om te werk aan, en gooi dit weg na herintegrasie die kode. Ons moet opweeg die tyd wat dit sal neem om hierdie kode teen die tyd dat ons kry deur sonder Rip Van Winkle soos ervarings met 'n vinnige hercompileren tydens ontwikkeling te herintegreer.

Orion het noem in 'n opmerking dat generiese n toneelstuk ook kan hê. Van my toetse daar verskyn 'n minimale prestasie treffer wees, maar nie hoog genoeg is om seker - stel tye kan teenstrydig wees as gevolg van skyf aktiwiteit. As gevolg van tydsbeperkinge, het my toetse sluit nie soveel Generiese, of soveel kode, as sou verskyn in lewende stelsel, sodat kan versamel. Ek sou nie verhoed dat die gebruik van generiese waar hulle veronderstel is om gebruik te word, net vir kompilering prestasie

Gelisensieer onder: CC-BY-SA met toeskrywing

Nie verbonde aan StackOverflow