Frågan#1
Tycker att det ser ganska bra ut... :)
http://www.gotdotnet.com/team/compare/petshop.aspx
Mvh, Vide
------------------
Mostly Harmless
benchmark mellan j2ee och .net
10 svar · 446 visningar · startad av Vide
Eftersom det är skillnader i de olika plattformarna och dess systemfunktioner, hur scripten körs kompileras mm. så är ett test av detta slaget inte så rättvist. .Net "grejerna" är ju kompilerad kod, Java "grejerna" interpreterande.
Visst man kan ju jämföra prestandan, men det är ju egentligen två skilda saker.
Det går säkert att få "Petshopen" att bli snabbare med andra metoder och system om man vill det.
/T
------------------
Jensen Ambassadör, mitt bästa köp! www.jensen.no
[Redigerat av Toonster den 24 jan 2002]
Bra artikel!
------------------
Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
Att göra en tokoptimerad portning av "The Java Petstore" och sedan triumfera att "Tjohoo, kolla så vrålsnabb vår implementation är" känns ganska världsfrånvänt.
J2EE Petshop är en referensimplementation som visar hur ett enterprisesystem byggs, det är knappast optimerat för snabbhet och det har heller aldrig varit tanken.
Att det går att skriva snabba och lasttåliga applikationer i Java är inget som man behöver tvivla på. Många är de system som snurrar på applikationsservrar skrivna i Java från främst IBM, Sun, Oracle och BEA. Dom klarar enorma laster utan att säcka ihop.
Toonster:
.Net "grejerna" är ju kompilerad kod, Java "grejerna" interpreterande.
Ok, jag är ingen .NET-expert, men rätta mig om jag har fel. .NET kompileras väl likt Java ned till ett intermidiärt format som tolkas av en virtuell maskin (Java) eller en CLR (.NET), i båda fallen kompileras koden till native-kod av en JIT.
------------------
Peer's Law
The solution to a problem changes the problem.
Det finns skillnader mellan en JVM och CLR. Det gäller mest design-valet.
C# (C#/IL/CLR) är till skillnad från Java (Java/Byte-kod/JVM) designat för att aldrig köras interpretat (de första JVM:erna var interpreterande). IL-koden har även större fördelar än byte-kod när det gäller att hantera flera språk, typer, generics eller templates (även om det inte finns i version 1.0).
C# hanterar språk-oberoende, vilket inte Java är designat för. Java är designat för plattformsoberoende, men det är även C# (även om det inte finns idag).
Prestandamässigt tror jag alltid man kan göra en C# applikation något snabbare än Java, men vi pratar inga 28 gånger. Jag tror Java Petstore skrivits annorlunda om man vetat att det senare skulle komma en motsvarande C# implementation.
Jag håller inte alls med sgtpepper om att det "...känns ganska världsfrånvänt" att göra en jämförelse. Enterprise applikationer behöver ofta designas för prestanda, och då är det väl konstigt att man i Java inte skulle kunna kombinera ett referenssystem med snabbhet?
Faktum kvarstår, Java Petstore bygger på vad Suns ingenjörer går ut och rekommenderar som en Best Practice på hur folk att bygga. Och det fungerar så länge man inte behöver hög prestanda, för då är designvalen i Java Petstore kanske inte de bästa. De system som kör Java med hög prestanda är ofta inte alls så enkla som Sun vill göra gällande. I min mening får man i C# lättare en kombination mellan enkelhet och hög prestanda.
Suns ingenjörer har ju dock fortfarande möjligheten att göra en snabbare implementation...
Jag håller inte alls med sgtpepper om att det "...känns ganska världsfrånvänt" att göra en jämförelse. Enterprise applikationer behöver ofta designas för prestanda, och då är det väl konstigt att man i Java inte skulle kunna kombinera ett referenssystem med snabbhet?
The Java Petstore är som sagt inte utvecklad mot prestanda, det är en överdesignat exempel.
Att sedan göra som MS, implementera en portning där man lägger i princip all logik i datalagret i form av stored procedures och sedan glatt ropa att "vår lösning går snabbare", det är det som jag menar är världsfrånvänt.
Självklart är det intressant att benchmark-testa olika tekniker, men att ta ett överdesignat MVC-system och jämföra det med ett system som lägger den mesta logiken i databasen känns varken rättvist eller så särskilt relevant.
Det enda som bevisas är i princip det som TheRegister skriver:
The .PET example proves little beyond that Wintel hardware provides more bang per buck than than old Sun hardware, but then we knew that anyway
------------------
Peer's Law
The solution to a problem changes the problem.
SgtPepper-> Man kan välja lite hur scripten interpreteras, kompileras och cachas.
JIT kompilatorn kan dessutom köras i två lägen, standard JIT och EconoJIT. Det senare mest vid utveckling (snabbare kompilering, större filstorlek).
Saxat ur "Pure ASP.Net", SAMS (förövrigt en ganska bra bok)
Unlike the Java Virtual Machine, wich interprets code at runtime, the Microsoft .Net runtime compiles in machine-native code, wich provides much better performance at runtime.
Utöver detta så finns då de sk. Assemblies, som resulterar i rena *.filer
------------------
Jensen Ambassadör, mitt bästa köp! www.jensen.no
Saxat ur "Pure ASP.Net", SAMS (förövrigt en ganska bra bok)
Med tanke på nedanstående så förstår jag "ganska" i meningen ovan:
"Unlike the Java Virtual Machine, wich interprets code at runtime, the Microsoft .Net runtime compiles in machine-native code".
Moderna JVM-er kör med Just-in-time-kompilering på samma sätt som .NET. Vad jag har förstått så kan man välja något som heter PreJIT i .NET som kompilerar IL-koden till native-kod INNAN exekveringen börjar och det är ju en viss skillnad, detta är dock inte default. Det vanliga (default JIT) är en method-by-method-kompilering i körningsögonblicket på "as-needed"-basis, på samma sätt som en Java JIT.
Jag skulle vilja säga att den ursaxade meningen från "Pure ASP.Net" är felaktig, något som dock inte är ovanligt i SAMS-böcker...
Utöver detta så finns då de sk. Assemblies, som resulterar i rena *.filer
Förstår inte vad du menar med *.filer. En assembly som jag förstått det är egentligen inget mer än en komponent bestående av IL samt ett metadata-manifest som består av information som behövs för att köra komponenten.
------------------
Peer's Law
The solution to a problem changes the problem.
[Redigerat av sgtpepper den 27 jan 2002]
Grejen är ju att JIT i .Net bara görs EN gång (om man så önskar, finns flera alternativ). I Java görs det ju varje gång class filen körs.
*.dll filer ska det vara... försvann lite i farten...
/T
------------------
Jensen Ambassadör, mitt bästa köp! www.jensen.no
[Redigerat av Toonster den 28 jan 2002]