[ASP.NET] een groot .dll bestand

[Folkert]

ben nu bezig met een website waarin bij het compilen de verschillende .vb files in een grote .dll worden omgezet. Nou wilde ik weten of een dergelijk grote dll (90kb) bepalend is voor de snelheid van de pagina. Ik heb een vij grote vertraging bij het oproepen van de pagina. De oorzaak hiervan weet ik nog niet helemaal. De viewstate is per pagina uitgeschakeld, alle datareaders en connections worden direct gesloten als ze zijn gebruikt maar toch blijft mijn pagina erg traag. Op het moment dat de pagina is geladen, is deze retesnel.

Dus vroeg ik me af in hoeverre een grote dll bepalend is voor de performance van de website. Is het misschien niet beter om per vb file een aparte dll te compilen?

[gorgi_19]

Nou wilde ik weten of een dergelijk grote dll (90kb) bepalend is voor de snelheid van de pagina

nee. En 90 kb vind ik nog niet zo heel groot.

Ik heb een vij grote vertraging bij het oproepen van de pagina

Kan kloppen; de eerste keer dat een applicatie opgeroepen wordt (en dit is global, dus niet voor iedere bezoeker), is deze traag

De viewstate is per pagina uitgeschakeld

Wat is hier het nut van? Hogouit scheelt dit bandbreedte, maar het lijkt me efficienter om een httpcompressiemodule er overheen te gooien.

[ Voor 28% gewijzigd door gorgi_19 op 07-02-2004 11:31 ]

[Folkert]

ok, dank voor je reactie! De dll file kan dus zo blijven. Ik neem dus aan dat deze op server niveau in het geheugen wordt geplaatst? Vertraging ligt dus toch aan iets anders.
En wat de viewstate betreft, ach elke overbodig bitje is er weer een...

En als ik zie hoeveel zooi er in wordt gestopt. Als het niet nodig is dan liever niet.

http compressie, ga ik uitzoek!

muchas gracias!

die 90 is idd niet erg groot, hij was 500kb aangezien ik met datasets werkte waar ik beter datareaders kon gebruiken dus dat scheelde een hoop overhead.

[ Voor 17% gewijzigd door Folkert op 07-02-2004 11:34 ]

[gorgi_19]

En wat de viewstate betreft, ach elke overbodig bitje is er weer een...

Mja.. Je maakt het jezelf zo wel een stuk moeilijker met postbacks; viewstate is niet per definitie overbodig..

Een datagrid, wat alleen gebruikt wordt voor presentatie --> viewstate kan uit
Een datagrid, welke ook bewerkingsmogelijkheden heeft --> viewstate scheelt werk.

die 90 is idd niet erg groot, hij was 500kb aangezien ik met datasets werkte waar ik beter datareaders kon gebruiken dus dat scheelde een hoop overhead.

erhm... Als ik een class aanroep van 600 kb in een andere assembly, wil niet zeggen dat mijn eigen assembly 600 kb is? Oftewel: lijkt me sterk dat je code zo enorm groot is doordat je datasets gebruikte.

[ Voor 67% gewijzigd door gorgi_19 op 07-02-2004 11:36 ]

[Folkert]

viewstate wordt alleen gebruikt waar het nodig is, dus idd bij postbacks maar in veel gevallen gaat het om weergave van data zonder een postback

[whoami]

Folkert schreef op 07 februari 2004 @ 11:33:
Vertraging ligt dus toch aan iets anders.

Idd, zoals gorgi_19 al aangaf:
De eerste keer dat je applicatie gerequest wordt (je applicatie wordt gestart), dan wordt de IL naar native code gecompiled. Vandaar dat het iets langer duurt.
Dat verklaart ook het feit dat de pagina daarna snel is: hij moet niet meer gecompiled worden, enkel de eerste keer dat hij gerequested wordt moet dat gebeuren.

die 90 is idd niet erg groot, hij was 500kb aangezien ik met datasets werkte waar ik beter datareaders kon gebruiken dus dat scheelde een hoop overhead.

Het lijkt wel alsof je hier zegt dat je assembly groter was omdat je een dataset gebruikt hebt ipv een datareader?

[Folkert]

Nou, allereerst ligt het aan mijn gebrekkige maar groeiende kennis van .NET
en daarbij wordt in VS.NET bij een aanmaken van een dataset een xsd bestand aangemaakt met een daarbij behorende vb file die mee wordt gecompiled bij een build. Ik had op deze manier meerdere datasets aangemaakt en hierdoor werden er dus vreselijk veel xsd + vb files aangemaakt.