[Java] Garbage Collection Nightmare?

[hobbit_be]

Af en toe zie ik hier een topic gewoon om meningen te vragen. Dit is er zo eentje.

Ik ben al (nog maar) een paar maand met Java bezig voor een project dat Content Management voor een website doet. We hebben zowel serverside als clientside spul. Nu dat het er bijna op zit heb ik toch een paar bedenkingen waar ik jullie mening es wil over horen.

1) Traag.
Eerlijk gezegd dacht ik dat dit geen probleem meer zou zijn, maar toch:

a) opstart snelheid.
Is het echt niet mogelijk om een java app snel te doen opstarten? Onze app die heus niet zoveel doet start op in 25-30 seconden, terwijl Visual Studio 6 dit op 5 seconden doet. (en Word in 2 . (met webstart nog trager)

b) processing speed van de meeste Open-Source libs.
We hebben ondervonden dat erg veel van open-source erg traag, buggy
'incompatible(xerces, xalan)'! is (specifiek in ons geval: Xindice, OJB, (Swing), XSP, Tomcat). Vaak moesten we erond werken ipv ermee. Soms dacht ik dat C veel crossplatform was dan Java...

c) UI - Swing. Dat het niet snel was dat wist ik al , maar hoe traag blijft me toch
echt verbazen: via AWT zal Java vast wel bitmaps kunnen 'blitten' en dus toch 1 of andere vorm van optimalistaties kunnen toepassen. de 'windowing' techniek (if any) is degoutant traag vind ik - het verschil met een native app is toch vaak 10x tot 20x keer zo traag. Ik heb zelf in (C++) maar wel met pure memcpy (dus GEEN blitting) een 32Bit windowing library (dus pure software versie) die 5x 10x keer sneller is. OOk het 'event' system is erg 'tricky' en niet echt responsive. En waarom duurt het altijd 5 - 10 na een minimize voor te hertekennen? Ik vind het erg jammer dat Sun met zoiets durft afkomen, ze hadden beter de resources in SWT gestoken. (Over swing kan ik nog uren doorzagen, en toch had ik al de beste boeken voor me (subscription op O'Reilly))

2) Memory

Het allerergste aan Java is het memory 'beheer' - we gebruiken voor ons spul Tomcat, Xindice, Cocoon en nog wat. Dit zijn allemaal server apps - maar alle stuk voor stuk vreten ze het geheugen op totdat ie op het punt 'of no return zit': ie elke volgende request gaat eerst gepaard met een hoop GC (soms enkele seconden, soms tientallen) en dan is het beter om te restarten. Tomcat is nog het beste van allemaal, Xindice is enorm 'slecht': we gebruiken nu 2MB aan xml data en toch na een uurtje van heel milde requests (1x minuut) zit het memory gebruik aan 160MB. onze eigen client app die ook bijna niets bijhoud (tis een live app dus kunnen we niet teveel cachen) slokt na een tijdje 60MB op.
Voor mij is het duidelijk : java (met Sun VM) is gewoon niet goed genoeg voor professioneel gebruik (wat enkele maanden door Sun zelf ook al werd gehint): en ja ik weet best dat J2EE heel vaak word gebruikt dus ik zal maar aannemen dat die een agressiever VM gebruiken, of ik iets heel grondig verkeerd doe. Of heb je echt een PIV+ met 1GB aan geheugen?

Maar graag daarover jullie mening, want ik begon heel hoopvol met dit project omdat Java toch erg aantrekkelijk leek - maar de hele toestand heeft me toch een slechte smaak van Java nagelaten. (net als de eerste keer 8 jaar geleden). (ik heb wel specifiek niet over applet of J2ME)

[Verwijderd]

Java is sloom met opstarten dat is een feit en is zover ik weer een niet op te lossen probleem. het laadverschil tussen een server en een vs6 is dat alle .class bestanen naar de gebruikerspc gestuurd moeten worden bij vc6 of word is dat dezelfde pc en via een server niet natuurlijk

[PommeFritz]

hobbit_be schreef op 04 May 2003 @ 00:09:
a) opstart snelheid.
Is het echt niet mogelijk om een java app snel te doen opstarten? Onze app die heus niet zoveel doet start op in 25-30 seconden, terwijl Visual Studio 6 dit op 5 seconden doet. (en Word in 2 . (met webstart nog trager)

Opstartsnelheid met Java JRE 1.3 of nieuwer valt best mee op een moderne PC.
java.exe is vrijwel direct opgestart en een doorsnee swing app doet er toch niet veel langer over dan 1 tot 5 sec. op mijn PC (athlon 1800). De SwingSet demo is in 5 seconden volledig geladen bij mij.
`

b) processing speed van de meeste Open-Source libs.
We hebben ondervonden dat erg veel van open-source erg traag, buggy
'incompatible(xerces, xalan)'! is (specifiek in ons geval: Xindice, OJB, (Swing), XSP, Tomcat). Vaak moesten we erond werken ipv ermee. Soms dacht ik dat C veel crossplatform was dan Java...

Mijn ervaring is tegenovergesteld: de meeste open source implementaties zijn just meer conform de standaards die er heersen. Kun je specifiek wat voorbeelden noemen waar het volgens jou dan buggy of incompatible is?

c) UI - Swing. Dat het niet snel was dat wist ik al , maar hoe traag blijft me toch
echt verbazen: via AWT zal Java vast wel bitmaps kunnen 'blitten' en dus toch 1 of andere vorm van optimalistaties kunnen toepassen. de 'windowing' techniek (if any) is degoutant traag vind ik - het verschil met een native app is toch vaak 10x tot 20x keer zo traag. Ik heb zelf in (C++) maar wel met pure memcpy (dus GEEN blitting) een 32Bit windowing library (dus pure software versie) die 5x 10x keer sneller is. OOk het 'event' system is erg 'tricky' en niet echt responsive. En waarom duurt het altijd 5 - 10 na een minimize voor te hertekennen? Ik vind het erg jammer dat Sun met zoiets durft afkomen, ze hadden beter de resources in SWT gestoken. (Over swing kan ik nog uren doorzagen, en toch had ik al de beste boeken voor me (subscription op O'Reilly))

Voor snellere graphics, verdiep je in de Java2D API. Voor de rest, Swing is geen snelheidsmonster nee. Maar b.v. JBuilder, die volledig Swing is, vind ik toch vrij behoorlijk mee te werken. Het is geen stroop i.i.g.

2) Memory

Het allerergste aan Java is het memory 'beheer' - we gebruiken voor ons spul Tomcat, Xindice, Cocoon en nog wat. Dit zijn allemaal server apps - maar alle stuk voor stuk vreten ze het geheugen op totdat ie op het punt 'of no return zit': ie elke volgende request gaat eerst gepaard met een hoop GC (soms enkele seconden, soms tientallen) en dan is het beter om te restarten. Tomcat is nog het beste van allemaal, Xindice is enorm 'slecht': we gebruiken nu 2MB aan xml data en toch na een uurtje van heel milde requests (1x minuut) zit het memory gebruik aan 160MB. onze eigen client app die ook bijna niets bijhoud (tis een live app dus kunnen we niet teveel cachen) slokt na een tijdje 60MB op.

Het lijkt erop dat er een memory leak zit in jullie applicatie en/of in Xindice.
Java gebruikt wel veel geheugen maar wat jij schrijft klinkt mij buitensporig in de oren.

Ben je op de hoogte van de opties waarmee je de VM memory size kunt tweaken? -Xms en -Xmx Tevens kun je (bij JDK 1.3+) kiezen tussen een client VM/JIT en een server VM/JIT, dit kan nogal verschil maken in performance/memory.

Voor mij is het duidelijk : java (met Sun VM) is gewoon niet goed genoeg voor professioneel gebruik (wat enkele maanden door Sun zelf ook al werd gehint): en ja ik weet best dat J2EE piheel vaak word gebruikt dus ik zal maar aannemen dat die een agressiever VM gebruiken, of ik iets heel grondig verkeerd doe. Of heb je echt een PIV+ met 1GB aan geheugen?

Ik heb nog geen J2EE server toepassingen gezien die perse meer dan 512 MB RAM nodig hebben. Ongetwijfeld zullen ze er zijn, maar er zijn ook "gewone" applicaties die gigabytes ram nodig hebben. Een 1 Gigaherz of sneller processor is altijd fijn, daar loopt de boel soepel op. Minder dan 1 Ghz is inderdaad niet aan te bevelen.

[Verwijderd]

Ik ben zelf ook niet al te lang bezig met java (anderhalf a twee jaar), maar werk nu veel met J2EE voor werk en ook met veel opensource software.

1a. Opstartsnelheid.
Opstartsnelheid van de vm is heel laag. Wij hebben ook een GUI (swing) voor heel onze applicatie en een command line interface die ook via java communiceert. Voor beide is de vm opstarttijd laag < 1 sec. Het grootste gedeelte van onze applicatie is ook server gebaseerd en daar is de opstarttijd niet relevant voor omdat de applicatie toch 24x7 moet draaien.
Wat doet je applicatie allemaal? Want 25 tot 30 seconden is wel heel veel..

1b. eigenlijk hetzelfde als onze PommeFritz hierboven al meldde. Xerces en Xalan (mits de juiste versies) werken zeer goed en zijn ook redelijk snel. Een native C implementatie is in de meeste gevallen wel sneller maar de opensource implementaties zijn zeker niet buggy of langzaam te noemen. Tja van je voorbeelden heb ik alleen gewerkt met Tomcat en ook daarmee weinig problemen ondervonden.

Om even terug te komen op xerces en xalan. Hier http://xmlbench.sourceforge.net/ staat een benchmark van verschillende xml parsers met features, snelheden en memory usage. Is wel interessant om te lezen.

Maar eigenlijk ben ik het in het algemeen met PommeFritz eens. De meeste opensource libraries waar ik mee gewerkt heb volgen de standaarden zeer strak, en buggy vindt ik nogal hard uitgedrukt. Er zitten net als bij 'normale' software bugs in, maar om het gelijk buggy te noemen vindt ik nogal ver gaan.

c. Swing is al lang veel kritiek op. Swing persoonlijk interesseert met niet echt veel. Ik zie zelf Java meer als iets voor de server als voor op de desktop. Het grote nadeel van swing is dat het heel makkelijk is om applicatie te ontwikkelen die niet echt responsive meer zijn. Toch is het ook goed mogelijk om met swing mooie, responsive en snelle applicatie te maken. Het vergt echter wat meer tijd en planning om het goed voor elkaar te krijgen. JBuilder is hierboven al genoemd, ook JEdit is een goed voorbeeld dat het wel snel/goed/mooi etc kan zijn.

Over SWT-Swing zijn genoeg discussies geweest dus zal ik verder maar geen woorden aan vuil maken

2. Memory
En weer ben ik het eens met PommeFritz. Java gebruikt idd veel geheugen, maar niet zo overdreven veel. Wij hebben een serverapplicatie lopen (J2ee met alles erop en eraan) stresstest van 10000 requests per uur (1 request zijn meerdere transacties) en het geheugen gebruik liep wel op naar 100mb maar niet meer.

De sun vm is idd niet de beste voor top performance. Maar is zeker wel bruikbaar voor professioneel gebruik. De meeste winst qua performance en memory gebruik is te halen door je applicatie eens goed te profile om te kijken waar nu eigenlijk de memory consumption in gaat zitten en welk gedeelte nu zo lang duurt.

De schuld geven aan Java en aan de sun vm is wel een erg makkelijke oplossing

[PommeFritz]

Verwijderd schreef op 04 May 2003 @ 21:20:
De meeste winst qua performance en memory gebruik is te halen door je applicatie eens goed te profile om te kijken waar nu eigenlijk de memory consumption in gaat zitten en welk gedeelte nu zo lang duurt.

Jij hebt het door

[curry684]

hobbit_be schreef op 04 mei 2003 @ 00:09:
ie elke volgende request gaat eerst gepaard met een hoop GC (soms enkele seconden, soms tientallen) en dan is het beter om te restarten.

Even negerend dat garbage collectors per definitie troep zijn en altijd dit soort problemen veroorzaken (uit iemand's sig hier op GoT komt de ware uitspraak: if there's no garbage in a language you don't have to collect it ) maar volgens mij kun je de GC wel 'tweaken' in C# en in mindere mate in Java. O.a. kun je volgens mij pointers expliciet nullen waardoor de destructie in principe meteen kan plaatsvinden, en in C# heb je de GC class die je eventueel zelfs kunt disablen en die je 'on demand' kunt aanschuppen.

Het lijkt me dat een forced garbage cleanup na iedere request al een hoop van je problemen zou moeten oplossen, vooral als je expliciet nullt om overbodige references op te lossen. Helaas weet ik niet of een forced cleanup in Java kan.

[Soultaker]

PommeFritz schreef op 04 May 2003 @ 02:13:
Opstartsnelheid met Java JRE 1.3 of nieuwer valt best mee op een moderne PC.
java.exe is vrijwel direct opgestart en een doorsnee swing app doet er toch niet veel langer over dan 1 tot 5 sec. op mijn PC (athlon 1800). De SwingSet demo is in 5 seconden volledig geladen bij mij.

VIJF SECONDEN op een Athlon 1800+! Ik heb de helft van die tijd nodig om Visual Studio te starten op m'n Pentium3 550 en dat is wel een redelijke applicatie van formaat. Noem je dat meevallen?

Een simpele Java AWT frame starten duurt ook al meer dan 2 seconden; vind ik ook lang. Swing gebruik ik zelf nooit dus dat kan ik zo snel even niet testen.

Voor snellere graphics, verdiep je in de Java2D API. Voor de rest, Swing is geen snelheidsmonster nee. Maar b.v. JBuilder, die volledig Swing is, vind ik toch vrij behoorlijk mee te werken. Het is geen stroop i.i.g.

Voor zover ik weet was het voor Java 1.4 niet mogelijk om op fatsoenlijke wijze vlotte graphics te produceren. Het verschil in snelheid tussen het blitten van een Java 1.4 VolatileImage en een 1.3 BufferedImage is gigantisch (ik heb helaas geen concrete gegevens meer beschikbaar).

Overigens zijn de door de topicstarter beschreven problemen niet uniek voor Java. Ook andere VM-bases talen (zoals bijvoorbeeld Python) hebben last van traagheid, absurd hoog geheugenverbruik en lange opstarttijden. Uiteraard geldt dat in een commerciële setting het upgraden (of bijplaatsen) van een extra server niet echt een groot probleem is, maar dat is nog geen argument om de problemen die er zijn maar te ontkennen. Het verschil tussen een Java client applicatie en (bijvoorbeeld) een native Win32 applicatie is enorm, ook al weet je dat van te voren wanneer je er voor kiest om een applicatie in Java te programmeren.

Verwijderd schreef op 04 May 2003 @ 21:20:
De meeste winst qua performance en memory gebruik is te halen door je applicatie eens goed te profile om te kijken waar nu eigenlijk de memory consumption in gaat zitten en welk gedeelte nu zo lang duurt.

Daar ben ik het niet mee eens. Je gooit dan het voordeel dat je ooit dacht te behalen door voor Java te kiezen weg om net zoveel tijd en moeite in optimalisatie van je Java applicatie te gaan steken als je in een C/C++ applicatie zou doen om uiteindelijk met een applicatie te zitten die nog steeds vele male trager is dan een vergelijkbare implementatie in C/C++. Als het je om efficiëntie te doen is, programmeer dan gelijk in C/C++, maar zorg dat als je voor Java kiest, je in ieder geval profiteert van de voordelen die dat wel biedt.

[ Voor 20% gewijzigd door Soultaker op 05-05-2003 03:42 ]

[pgussow]

Het grote voordeel dat Sun met Java wilde bereiken was platform-onafhankelijk ontwikkelen. En dan is het logisch dat je wat performance inleverd.

In zo goed als iedere serieuze programmeer-taal kun je memory-leaks hebben, dus ook in Java. Java ruimt de meuk op als er geen REFERENCE meer is naar dat object. Maar het kan zo maak zijn dat je per ongelukt nog een reference naar een object in een vectortje hebt staan. Er bestaat nog een reference -> GC ruimt het niet op -> Er is geboren: Een memory leak...

[Verwijderd]

Soultaker schreef op 05 mei 2003 @ 03:36:
VIJF SECONDEN op een Athlon 1800+! Ik heb de helft van die tijd nodig om Visual Studio te starten op m'n Pentium3 550 en dat is wel een redelijke applicatie van formaat. Noem je dat meevallen?
[...]

Dit is wel een beetje appels met peren vergelijken. Ms visual studio op een windows platform. Waarvan de ontwikkelaars ervan direct toegang hebben tot alle vage api calls van het onderliggende OS. Natuurlijk gaat dat vele malen sneller dan het opstarten van een Java applicatie. Maar visual studio werkt niet op Solaris, en niet op Linux en niet op Mac OS etc... etc...

Daarentegen betaal je wel een prijs in performance en memory gebruik.

Het verschil tussen een Java client applicatie en (bijvoorbeeld) een native Win32 applicatie is enorm, ook al weet je dat van te voren wanneer je er voor kiest om een applicatie in Java te programmeren.

Dit ben ik dan toch wel met je eens. Ik vindt java ook geen taal voor client / gui applicaties. Zoals ik al vaker heb lopen roepen, java is meer voor de server.

Daar ben ik het niet mee eens. Je gooit dan het voordeel dat je ooit dacht te behalen door voor Java te kiezen weg om net zoveel tijd en moeite in optimalisatie van je Java applicatie te gaan steken als je in een C/C++ applicatie zou doen om uiteindelijk met een applicatie te zitten die nog steeds vele male trager is dan een vergelijkbare implementatie in C/C++. Als het je om efficiëntie te doen is, programmeer dan gelijk in C/C++, maar zorg dat als je voor Java kiest, je in ieder geval profiteert van de voordelen die dat wel biedt.

Ik wil niet zeggen dat je iedere applicatie die je maakt moet profilen. Als je netjes ontwerpt en net programmeert zul je weinig problemen tegenkomen. Het gaat mij niet om het optimaliseren om elke procent extra performance eruit te persen. Als je echter vreemde zaken krijgt zoals de topicstarter meldde dan zul je door een profiler te draaien zeer snel zien waar het probleem zit.
De meeste applicaties gaan niet om efficientie, de meeste programma's moeten gewoon doen wat de bedoeling is dat ze doen. 5% meer performance halen door weken lang te lopen pielen is in de meeste gevallen niet rendabel. Als je complexe algortithmes hebt, ok gebruik dan C/C++. Maar ik ben het totaal niet met je eens dat het profilen van een java app (wat echt niet veel tijd kost) alle voordelen van java teniet doen en net zoveel tijd kosten als eenzelfde applicatie in C++ opzetten.

[PommeFritz]

Zoals Donald Knuth het all zei; Premature optimization is the root of all evil.
Wat ik ook vaak heb meegemaakt is dat een enorme snelheidsverbetering haalbaar is door slim je datastructuren en je algorithmes te kiezen, een quicksort in Java is vele malen sneller dan een bubblesort in C++. Een hashtable in Java is vele malen sneller dan een lineaire lookup lijst in C++.
Java kan traag zijn ja. Vooral client side merk je dit sneller omdat je snappy GUI feedbacks gewend bent (terecht overigens!). Maar Java kan ook heel snel zijn. Ik heb ooit eens een enorm XML document door een C++ XML parser gehaald en die was maar weinig sneller dan een Java XML parser... (Xerces C++ vs Xerces Java).

Als je echt een performance kritisch stuk code hebt waarvan je kunt aantonen dat het aan Java of Python ligt, dan kun je ervoor kiezen om alleen dat stukje in C++ te schrijven en middels JNI of de Python Extension API aan te spreken. Vergelijk dit met wat we vroeger deden; kleine stukjes Assembler in je C programma om die kritische functies te versnellen. Maar je schrijft niet je hele programma in assembler omdat dat niet te doen is.

[hobbit_be]

Aan alle comments - bedankt, we gaan hier alvast eens met de profiler werken (tja dat komt ervan als je Top Down werkt (ie Java zonder ook maar 1 keer java.exe in te voeren) en zeker met de settings van de VM.

Ik ben het eens dat optimalisatie pas later moet gebeuren - maar ons design zit al vol met Hashes, Caches qua design concept. Dus sneller lijkt niet echt te lukken. Gelukkig hebben we vernomen dat de target PC's PIV 2.4Ghz zullen zijn. Das toch zo'n 10-20 sneller dan mijn develop bakje.

Qua leaks - als ik aObject == null; moet gaan doen in Java dan ga ik maar liever C++ terug; Overigens dit truukje helpt helemaal niet: de GC weet dat 100% zeker dat ie Released moet worden maar hij gaat dit pas doen wanneer hij Out Of Mem runt, wat net het probleem is. In mijn jaren als C++ let ik echt wel ok of meerdere refs overblijven.

Dat artikle Xerces vond ik wel interessant, helaas blijkt daar de delay niet te zitten, omdat we aan 'modern' xml design wilde doen gebruiken we 'XPath/XSLT' in onze code - daarvoor gebruiken we een parsed DTM. Die lijkt nogal wat geheugen te 'swallowen' we zijn die nu aan het vervangen door een eigen mini-Xpath parsertje die gewoon op de DOM werkt.

We gebruiken ook Log4J nogal heftig - en die blijkt ook nogal wat op te slorpen (que performance, we zullen heel wat debug statements weg moeten doen, wat jammer is), maar zelfs met een paar enkele gevallen is het verschil merkbaar. Note de delay zit em in het aanmaken van de string die ie door moet geven -= we laten niet alled debug zien (level = WARN) , Is er in Java eigenlijk geen support zoals #ifdef.

Swing - tja we houden ons hart vast om te zien hoe ze reageren. Het ziet er in ieder geval deftig uit.

Jullie vroegen af wat ie allemaal deed: ons systeem gebruikt xml om de applicatie de beschrijven en de app is dus mee een App-framework. IE: alle UI zit in XML beschreven die moet worden geparsed voor elke UI dat word opgebouwd: alle 'templates' worden natuurlijk wel gecached - maar deze UI templates zitten allemaal leuk op een server-side XML-database (net zoals de hele 'app'), voor de rest zit er een HTML editor in (zonder tables ) - een OJB engine (eigenlijk 2) - auto conversie routines: ie stel je maakt een Convertor voor Date -> String en aan Calendar -> String dan kan het systeem ook ineens Calendar -> String aan. Verder: een excel - style record editor (voor het overzien van 10.000+ records die worden moeten worden bekeken, allemaal gecached hoort we laden alleen een 100tal gelijk in, de rest word allemaal met threading geload als erom moet worden gevraagd), record editor (ook volledige gedefineerd in XML nattrulijk, zonder ook maar een hint van SQL), allemaal met realtime validation (enkele honderden 'types'), Cascading Updates, Delete, een 50 tal tables (heel erg cross - linked, maar wel goed design). Maar eigenlijk 'doet' het niet veel - gewoon een Windowke dynamisch aanmaken enzo.

Dit alles maakt het mogelijk de app te veranderen terwijl ie draait (ook business logic is beshreven in XML zodat ) mits in 'design' mode. Dit moest wel want het hardcoden van deze CMS / IT solution leek ons net iets onhandigs... Het moet ook herbruikt kunnen worden en aangepast voor eender welke site (wat ie dus aankan).

Dat Java==Server vind ik wel erg jammer,maar daarvoor hoor ik geen tegencommentaar. Ik gebruik JBuilder als IDE en ik word verplicht elke 45minuten of zo deze te herstarten omdat ie al mijn geheugen heeft opgevreten (toch 512Mb) en dus elke restart van de app minuten duurt.

Nou goed we hebben hier erg veel uit geleerd.

Het XIndice probleem (de open-source xml-db server) blijft wel, alsook Cocoon. We hebben Xindice eens grondig gestressed en die begon na een tijd Errors met WeakRef's te gooien. We hebben dan maar een cron-job geplaatst... (maar helaas moet Cocoon dan ook worden herstart).

Bedankt! - en laat maar komen die comments.

[curry684]

hobbit_be schreef op 05 May 2003 @ 14:05:
de GC weet dan 100% zeker dat ie Released moet worden maar hij gaat dit pas doen wanneer hij Out Of Mem runt

Vandaar ook dat ik erbij zei dat je eens moest kijken of je de GC een forced cleanup kon laten doen

C# ondersteunt het namelijk in ieder geval wel, zoals hier getoond.

[Glimi]

curry684 schreef op 05 May 2003 @ 14:20:
Vandaar ook dat ik erbij zei dat je eens moest kijken of je de GC een forced cleanup kon laten doen

C# ondersteunt het namelijk in ieder geval wel, zoals hier getoond.

In Java is dat System.gc(). Je blijft dan wel niet weten waarneer de gc() aangeroepen gaat worden, maar dat zal toch wel in een redelijke tijd gebeuren
Verder kan ik ook de -server optie aanraden. Volgens mij zou dat wel wat moeten schelen

Verder moet je even analyseren waar het geheugen heen gaat. Zijn het objecten die lang blijven leven of zijn het objecten met een korte levensduur. Anders moet je eens kijken of je de mem taktiek van de VM kan aanpassen naar gelang de manier, dwz kijken of je Stop & Copy kan forceren, een generational collector oid of gewoon plain Mark & Sweep

[Janoz]

hobbit_be schreef op 05 May 2003 @ 14:05:
We gebruiken ook Log4J nogal heftig - en die blijkt ook nogal wat op te slorpen (que performance, we zullen heel wat debug statements weg moeten doen, wat jammer is), maar zelfs met een paar enkele gevallen is het verschil merkbaar. Note de delay zit em in het aanmaken van de string die ie door moet geven -= we laten niet alled debug zien (level = WARN) , Is er in Java eigenlijk geen support zoals #ifdef.

Wij gebruiken zelf altijd de volgende constructie:

Java:

    if (infoEnabled) log.info("ElementDAO.findElemetsByQuestionId() called.");

Op deze manier wordt er niet een nieuw string object aangemaakt. Zeker waneer er veel stringconcatenaties worden gedaan scheelt dat wel een beetje (Het is wat suf om een debug message te genereren (strungbuffer aanmaken, string objecten aanmaken ed) om deze vervolgens rechtstreeks naar de gc te sturen .

[Soultaker]

Verwijderd schreef op 05 mei 2003 @ 08:53:
Dit is wel een beetje appels met peren vergelijken. Ms visual studio op een windows platform. Waarvan de ontwikkelaars ervan direct toegang hebben tot alle vage api calls van het onderliggende OS. Natuurlijk gaat dat vele malen sneller dan het opstarten van een Java applicatie. Maar visual studio werkt niet op Solaris, en niet op Linux en niet op Mac OS etc... etc...

Dat is flauw: wie begint er nu over dat Java niet traag zou zijn? Dan vergelijk ik Java met andere platforms waar ik gebruik van maak (native Windows, in dit voorbeeld, maar ook bijvoorbeeld FreeBSD) en daaruit concludeer ik dat Java wel degelijk heel veel trager is. Ik kan de bewering dat Java niet traag is nooit ontkrachten als ik die vergelijking niet mag maken. Ik kan je wel gelijk geven dat Java in vergelijking met Python niet traag is, maar dat zegt me niets: ze zijn beide traag vergeleken met gebruikelijke platforms.

Verder moet je gewoon maar je keuze maken en je bij je beslissing neerleggen. Als je voor Java kiest om sneller stabielere applicaties te ontwikkelen, dan offer je daar wat opstart- en executiesnelheid (en wat geheugen) voor op. Ik kan me goed voorstellen dat dat een zinnige trade-off is in veel situaties, maar geef dan gewoon toe dat Java niet het snelste platform is.

Overigens gebruikt Visual Studio volgens mij niet zoveel 'vage API calls', want het werkt goed onder alle Windows versies die ik ken (in ieder geval 98, 2000 en XP). Ze zullen dan toch wel enigszins conformerend aan de standaarden te werk gaan en voor zover ik weet zijn alle standaard API calls gedocumenteerd en voor iedereen beschikbaar. Ik heb meer het idee dat ze op Visual Studio goede programmeurs zetten (omdat het belangrijk is om andere ontwikkelaars tevreden te houden) en dat 't daarom vlot en stabiel draait. Er zijn trouwens ook zat Windows-applicaties die snel opstarten die niet door Microsoft ontwikkelt zijn.

[hobbit_be]

Janoz: ja daar dacht ik nu ook net aan hopelijk is daar een refactor voor Lelijk als F*** maar ben je wel zeker zo. Soms is de debug text ECHT wel groot dus dit gaat vast helpen

Glimi: tja die System.gc() staat ook in JBuilder maar die doet helemaal niets bij mij hoor - op een of ander forum gelezen dat ie ook niet echts iets doet... Ik zoek naar een 'Aggresivity' Level voor een GC, bestaat dat in C# ? (ie level 0 = delete immediate after no ref, 5 = delete when idle > 50% cpu time)...Maar wat doet die -server ? De objecten zijn meestal long lived (ie Cache)

[PommeFritz]

hobbit_be schreef op 05 mei 2003 @ 14:05:
Qua leaks - als ik aObject == null; moet gaan doen in Java dan ga ik maar liever C++ terug; Overigens dit truukje helpt helemaal niet: de GC weet dat 100% zeker dat ie Released moet worden maar hij gaat dit pas doen wanneer hij Out Of Mem runt, wat net het probleem is.

Je hoeft natuurlijk alleen maar mijnObject = null; te doen als het niet een object betreft dat gewoon op de stack frame staat en netjes geunwind wordt als je terug springt uit de method. Dwz alle "tijdelijke" objecten die je alloceert in een method worden gewoon vrijgegeven als de method verlaten wordt...

[Verwijderd]

Java is niet snel, maar zeker ook niet bagger langzaam. Echter wordt je bij java erger gestraft voor programmeer 'fouten'. neem bijvoorbeeld:

code:

for (i=0;i<10;i++) {
  Object aObject;
  aObject= ... 
  ..(aObject)..
}

is onder java veel inefficienter dan onder C of C++ en zou je zeker moeten veranderen naar:

code:

Object aObject;
for (i=0;i<10;i++) {
  aObject=...
  ...(aObject)..
}

maar er zijn meer truuctjes om java wat beter te laten presteren. Namelijk expliciet de garbage collector aanroepen met 'System.gc();'. Dit doe je vooral na grote algoritmen die veel tijdelijke objecten gebruiken, en helemaal als dit gevolgd wordt door een stukje dat veel wacht (op events bijvoorbeeld).

Ook is in veel gevallen een Hashtable een veel efficientere data opslag structuur dan een Vector (als er wat te hashen valt uiteraard).

Ach, java is niet super snel en vreet geheugen, maar voordelen boven C/C++ zijn er miljoenen, niet alleen geheugen management wordt uit handen genomen, maar ook type safety, makkelijke thread safety enzovoorts is veel beter geregeld. Deze voordelen wegen zeker op tegen minder safe languages. Wat doe je als je website 'segfault' .. ?

Ook over platform onafhankelijkheid: een .class werkt echt op elk platform (mits java versies overeenkomen), dat is pas echt goed in te zien op het moment dat je het zelf meemaakt; Een op een Mac OS X gemaakte app draait onder windows, linux, maar ook op de iPaq .. echt amazing.

[Verwijderd]

Dat is flauw: wie begint er nu over dat Java niet traag zou zijn? Dan vergelijk ik Java met andere platforms waar ik gebruik van maak (native Windows, in dit voorbeeld, maar ook bijvoorbeeld FreeBSD) en daaruit concludeer ik dat Java wel degelijk heel veel trager is.

Dat ontken ik toch ook niet. Het ging mij er gewoon om dat je de opstartijd van een java applicatie (inclusief de java vm) vergelijkt met het opstarten van een native app. En aan het opstarten verbind je dan gelijk de conclusie dat Java langzaam is.

.. ze zijn beide traag vergeleken met gebruikelijke platforms.

In stuk code geschreven in assembly is sneller dan een stuk code in C/C++ Dit maakt C++ toch ineens ook niet traag.

Verder moet je gewoon maar je keuze maken en je bij je beslissing neerleggen. Als je voor Java kiest om sneller stabielere applicaties te ontwikkelen, dan offer je daar wat opstart- en executiesnelheid (en wat geheugen) voor op. Ik kan me goed voorstellen dat dat een zinnige trade-off is in veel situaties, maar geef dan gewoon toe dat Java niet het snelste platform is.

Dat heb ik ook al lang toegegeven, als je mijn berichtje leest staat duidelijk dat voor oa. platformonafhankelijkheid en memory management betaal je wel een prijs in performance en memory gebruik. Ik wil je heus niet overtuigen wat een godsgeschenk java is en voor maximale performance kun je beter je app of die specifieke routine maken in c/c++ (of assembly als je daar plezier in hebt). Ik wil alleen aangeven dat java geen sloom systeem is

Overigens gebruikt Visual Studio volgens mij niet zoveel 'vage API calls', want het werkt ......... zijn trouwens ook zat Windows-applicaties die snel opstarten die niet door Microsoft ontwikkelt zijn.

Zoals ik al gezegd heb het gaat mij daar niet over. Ik wil alleen zeggen dat het niet vreemd is dat een applicatie gemaakt door Microsoft, en dat draait op een door microsoft ontwikkeld OS geen eerlijke vergelijking is qua opstarttijd met een programma dat gebruik maakt van een virtual machine.

[curry684]

Ik zoek naar een 'Aggresivity' Level voor een GC, bestaat dat in C# ? (ie level 0 = delete immediate after no ref)

LOL nee dan zou het ding nuttig zijn, dus die optie wordt nergens geboden.

En tot die tijd vallen alle Garbage Collectors onder de Garbage die ze zelf moeten Collecten

[curry684]

Zoals ik al gezegd heb het gaat mij daar niet over. Ik wil alleen zeggen dat het niet vreemd is dat een applicatie gemaakt door Microsoft, en dat draait op een door microsoft ontwikkeld OS geen eerlijke vergelijking is qua opstarttijd met een programma dat gebruik maakt van een virtual machine.

En dat slaat zoals Soultaker al zei nergens op. Er zijn geen undocumented API-calls, en al zeker geen 'make my cpu run twice as fast' API-calls. Het verschil zit 'm in dat Visual Studio native C++ is, en dat Java een bytecode interpreted language is met gegeneraliseerde platform independent libraries. Drop the paranoia please.

[hobbit_be]

Janoz: heb net even over heel de app (350 files, helaas manueel) alle debug statements met een if gemaakt - het verschil is echt enorm - qua 'gevoel' is het zeker 2x 3x maal zo snel. Tjongens, en qua geheugen scheelt het ook echt enorm. In C/++ doe ik niets anders dan ASSERTs maar had er nooit bij stilgestaan dat bij Java dat idd allemaal werd uitgevoerd (nou wist ik wel, maar ik dacht niet aan een zware 'penalty' ofzo).

[hobbit_be]

curry684 schreef op 05 May 2003 @ 17:03:
[...]

LOL nee dan zou het ding nuttig zijn, dus die optie wordt nergens geboden.

En tot die tijd vallen alle Garbage Collectors onder de Garbage die ze zelf moeten Collecten

toh wel gek vind je niet? lijkt mij toch bijzonder interessant om WEL te hebben...

[curry684]

hobbit_be schreef op 05 May 2003 @ 17:08:
[...]
toh wel gek vind je niet? lijkt mij toch bijzonder interessant om WEL te hebben...

Dan moet je C++ pakken en een goed smartpointered systeem gebruiken. Dan werken je destructors plots wel op het goede moment en gegarandeerd.

Garbage Collection is, contrary to popular belief, geen advanced feature die een programmeertaal prettiger mee te werken maakt. Het is een workaround om idiote programmeurs tegen excessen te beschermen. En in ruil daarvoor lever je een stuk controle en, zoals jij nu merkt, snelheid in.

* curry684 kent trouwens ook C/C++ programmeurs die principieel blokken geheugen kleiner dan ~100 bytes niet vrijgeven

[ Voor 2% gewijzigd door curry684 op 05-05-2003 18:55 . Reden: Misklik... ]

[Glimi]

hobbit_be schreef op 05 May 2003 @ 15:34:
Glimi: tja die System.gc() staat ook in JBuilder maar die doet helemaal niets bij mij hoor - op een of ander forum gelezen dat ie ook niet echts iets doet...

Redelijk apart? Misschien is ie te druk (kan het me haast niet voorstellen...). Maarja kijk hier nog es naar : http://java.sun.com/j2se/...ows/java.html#nonstandard
En dan vooral naar de opties mbt incrementele gc en gc-logging
De server optie staat daar geloof ik ook omschreven

[Soultaker]

Verwijderd schreef op 05 May 2003 @ 16:53:
Dat heb ik ook al lang toegegeven, als je mijn berichtje leest staat duidelijk dat voor oa. platformonafhankelijkheid en memory management betaal je wel een prijs in performance en memory gebruik. Ik wil je heus niet overtuigen wat een godsgeschenk java is en voor maximale performance kun je beter je app of die specifieke routine maken in c/c++ (of assembly als je daar plezier in hebt). Ik wil alleen aangeven dat java geen sloom systeem is.

Over de exacte bewoordingen wil ik niet discussieren, maar mijns inziens kun je niet zeggen dat je enerzijds een "prijs in performance en memory gebruik" betaalt maar dat anderzijds Java niet trager is dan C/C++. Wat is het nu? Is het nu wel of niet merkbaar trager? Ik denk van wel. Dat is geen reden om nooit Java te gebruiken, maar het is wel een nadeel van het Java platform en dat ontkennen vind ik kortzichtig en onverstandig.

Zoals ik al gezegd heb het gaat mij daar niet over. Ik wil alleen zeggen dat het niet vreemd is dat een applicatie gemaakt door Microsoft, en dat draait op een door microsoft ontwikkeld OS geen eerlijke vergelijking is qua opstarttijd met een programma dat gebruik maakt van een virtual machine.

Nu mag ik het Java platform dus ook niet vergelijken met software die ontwikkeld is door mensen die hun vak verstaan en met een platform dat goed werkt en door met afstand het grootste deel van de bevolking gebruikt wordt? Ja, zo kan ik ook beredeneren dat Java best wel heel erg goed is. Feit blijft dat het Microsoft platform en Microsoft software een heel groot deel van de softwaremarkt vullen. Het lijkt me dan ook logisch om je bij een vergelijking juist op gangbare applicaties te richten.

[ycode]

Een System.gc() doet een request voor garbage collect, hij doet die dus niet meteen. Je kunt een garbage collect niet forceren. (Uit Java Programmer exam van Sun)

[MSalters]

curry684 schreef op 05 mei 2003 @ 18:37:
* curry684 kent trouwens ook C/C++ programmeurs die principieel blokken geheugen kleiner dan ~100 bytes niet vrijgeven

En? Heb ook wel eens een blok van 400Mb+ geleakt. Zolang je dat precies één keer in een programma doet...

[Verwijderd]

Soultaker schreef op 05 May 2003 @ 18:48:
Over de exacte bewoordingen wil ik niet discussieren, maar mijns inziens kun je niet zeggen dat je enerzijds een "prijs in performance en memory gebruik" betaalt maar dat anderzijds Java niet trager is dan C/C++. Wat is het nu? Is het nu wel of niet merkbaar trager? Ik denk van wel. Dat is geen reden om nooit Java te gebruiken, maar het is wel een nadeel van het Java platform en dat ontkennen vind ik kortzichtig en onverstandig.

Ik zeg nergens dat Java niet trager is als C/C++ . Voor performance is C/C++ beter. Zoals ik ook al in het gedeelte dat je quote heb gezegd. Je wilt weten of het merkbaar trager is, ik denk van niet. In java voor client side applicaties is het wel te merken, maar zoals ik al hele tijd loop te zeggen, maak een vergelijking met server gebaseerde applicaties en bepaal dan of je het merkzaam langzamer vindt.
Baseer niet het feit dat de een java client applicatie langzamer opstart en minder responsive is dan een native windows applicatie dat gelijk maar heel de taal heel veel trager is dan C/C++.

Nu mag ik het Java platform dus ook niet vergelijken met software die ontwikkeld is door mensen die hun vak verstaan en met een platform dat goed werkt en door met afstand het grootste deel van de bevolking gebruikt wordt? Ja, zo kan ik ook beredeneren dat Java best wel heel erg goed is. Feit blijft dat het Microsoft platform en Microsoft software een heel groot deel van de softwaremarkt vullen. Het lijkt me dan ook logisch om je bij een vergelijking juist op gangbare applicaties te richten.

Je mag java overal mee vergelijken waar je mee wilt vergelijken, maar om een hele taal als traag, sloom etc. te bestempelen omdat je applicatie niet in 2 seconden opstart maar in 5 seconden vindt ik nogal kort door de bocht.

[curry684]

MSalters schreef op 05 May 2003 @ 19:11:
[...]
En? Heb ook wel eens een blok van 400Mb+ geleakt. Zolang je dat precies één keer in een programma doet...

Doe je het ook principieel terwijl je het weet? Terwijl een simpele delete je in de toekomst problemen kan schelen als die 400Mb plots wel vaker nodig is?

[Soultaker]

Even quoten:

Verwijderd schreef op 05 May 2003 @ 21:06:
Je wilt weten of het merkbaar trager is, ik denk van niet. In java voor client side applicaties is het wel te merken

Wat is het nu? Wel te merken of niet te merken? Als het voor client side applicaties wel merkbaar is, dan is het toch merkbaar? Of telt dat ook niet?

maar zoals ik al hele tijd loop te zeggen, maak een vergelijking met server gebaseerde applicaties en bepaal dan of je het merkzaam langzamer vindt.

Ja hoor, ook dan is het langzamer. Verschil is dat als een server slecht presteert je er wat geheugen bijprikt of er een tweede server naast zet, wat je met een gewone client PC niet kan doen. Als je serieus onderzoekt, zul je merken dat op vrijwel alle gebieden native C/C++ (of iets anders) code een stuk sneller is dan Java code.

Baseer niet het feit dat de een java client applicatie langzamer opstart en minder responsive is dan een native windows applicatie dat gelijk maar heel de taal heel veel trager is dan C/C++.

Waar mag ik het dan wel op baseren? In theorie kun je zo'n beetje alle talen wel optimaliseren naar dezelfde utopische executie, maar in de praktijk legt het Java platform de ontwikkelaar een aantal beperkingen op en zul je daar mee moeten leren leven. Het gaat daarbij niet zozeer om de taal Java maar vooral om het Java platform waar de taal Java voor bedoelt is.

Je mag java overal mee vergelijken waar je mee wilt vergelijken, maar om een hele taal als traag, sloom etc. te bestempelen omdat je applicatie niet in 2 seconden opstart maar in 5 seconden vindt ik nogal kort door de bocht.

Als de stelling klopt dat een gangbare applicatie in 2 seconden start en een Java applicatie in 5 seconden, dan vind ik het niet "kort door de bocht" om tot de conclusie te komen dat java traag start. Overigens gelden vergelijkbare waarden voor het gebruik na het starten (zoals de topic starter al aangaf).

Nu hebben we die 2/5 seconden niet echt objectief vastgesteld en is de opstarttijd maar een enkel aspect, maar als gegeven zou zijn dat Java 2,5 keer zo langzaam is als een native C/C++ applicatie, dan durf ik met recht te stellen dat Java traag is. Inderdaad is C/C++ code ook al snel 2,5 keer zo traag als pure assembly, maar feit is dat applicaties geschreven in assembly niet gangbaar zijn. Bij specifieke toepassingsgebieden van assembly is inderdaad ook bekend dat C/C++ traag is, vandaar dat op beperkte schaal algoritmen ook in assembly geschreven worden om een performance winst te behalen.

[curry684]

Soultaker schreef op 05 mei 2003 @ 21:50:
maar feit is dat applicaties geschreven in assembly niet gang haalbaar zijn.

Bij specifieke toepassingsgebieden van assembly is inderdaad ook bekend dat C/C++ traag is, vandaar dat op beperkte schaal algoritmen ook in assembly geschreven worden om een performance winst te behalen.

Correct tot op zekere hoogte. Ik heb jarenlang pure assembler geprogrammeerd en versloeg welzeker alle C en C++ compilers met verve. Helaas waren dat de 6502 en 680x0 processors Ik heb nog moeten afleren self-modifying code te gebruiken toen de 68020 gangbaar werd met z'n 256 bytes cache.

Tegenwoordig zijn de optimalisatiealgoritmes afgestemd om code zo in mekaar te bakken dat het alle voordelen trekt uit 13 parallele processing pipelines met afzonderlijke branchprediction, en de compilers houden rekening met de boundaries van 1Mb cache. Daar kun je als assemblerprogrammeur botweg niet meer tegenop.

Assembler is nog welzeker nuttig (ik kan nog vloeiend debuggen op x86 overigens) maar wel in geisoleerde gebieden zoals datablokmanipulatie, task schedulers en low-level IO's. Zodra je programma een beetje formaat wordt zal de C/C++ compiler de beste ASM-coder ver achter zich laten.

[.oisyn]

Verwijderd schreef op 05 mei 2003 @ 21:06:
[...]

Ik zeg nergens dat Java niet trager is als C/C++ . Voor performance is C/C++ beter. Zoals ik ook al in het gedeelte dat je quote heb gezegd. Je wilt weten of het merkbaar trager is, ik denk van niet. In java voor client side applicaties is het wel te merken, maar zoals ik al hele tijd loop te zeggen, maak een vergelijking met server gebaseerde applicaties en bepaal dan of je het merkzaam langzamer vindt. Baseer niet het feit dat de een java client applicatie langzamer opstart en minder responsive is dan een native windows applicatie dat gelijk maar heel de taal heel veel trager is dan C/C++.

En juist bij de server apps worden de 'vage API calls' waar jij (geloof ik) het in het begin van de thread over had belangrijk. Windows biedt bijvoorbeeld allemaal mooie synchronizatie objecten en functies om je threads te synchronizeren aan files, sockets, streams en weet ik veel wat voor zooi. Java mist al die dingen. En zeker bij ingewikkelde server applicaties die honderden of zelfs duizenden connecties moet afhandelen en veel file access heeft zijn dit essentiele dingen. Memory mapped files? Overlapped read-writes? Allemaal niet beschikbaar in java.

Dan vind ik het portability argument van java persoonlijk erg mager... of ze moeten deze dingen eens in de (j2ee) API opnemen

[PommeFritz]

.oisyn: kijk eens aan: http://java.sun.com/j2se/1.4.1/docs/guide/nio/index.html ...
(jdk 1.4+)

[ Voor 1% gewijzigd door PommeFritz op 05-05-2003 23:52 . Reden: spelfout ]

[Verwijderd]

Zo verse bak koffie voor m'n neus, we kunnen weer

Ik zal ook maar weer eens beginnen met wat te quoten:

Soultaker schreef op 05 May 2003 @ 21:50:
Wat is het nu? Wel te merken of niet te merken? Als het voor client side applicaties wel merkbaar is, dan is het toch merkbaar? Of telt dat ook niet?
[..]
Ja hoor, ook dan is het langzamer. Verschil is dat als een server slecht presteert je er wat geheugen bijprikt of er een tweede server naast zet, wat je met een gewone client PC niet kan doen. Als je serieus onderzoekt, zul je merken dat op vrijwel alle gebieden native C/C++ (of iets anders) code een stuk sneller is dan Java code.

Ik zeg toch ook nergens dat Java sneller of even snel is dan C/C++ code. En zoals ik ook al gezegd heb bij grote client apps is het best merkbaar dat het minder responsive is dan een native applicatie. Maar alleen omdat C/C++ sneller is maakt Java niet ineens traag. Je gaat er zo'n beetje van uit dat Java per definitie slecht presteert en altijd merkbaar traag is.

maar in de praktijk legt het Java platform de ontwikkelaar een aantal beperkingen op en zul je daar mee moeten leren leven.

En wat zijn dan al zoal al die beperkingen waar ik mee moet leren leven? Memory management is ook een beperking van C/C++ waar je mee moet leren leven. Zo heeft elke taal/platform wel iets.

Als de stelling klopt dat een gangbare applicatie in 2 seconden start en een Java applicatie in 5 seconden, dan vind ik het niet "kort door de bocht" om tot de conclusie te komen dat java traag start. Overigens gelden vergelijkbare waarden voor het gebruik na het starten (zoals de topic starter al aangaf).

Java start ook trager, maar dat maakt niet gelijk heel de taal langzaam (hmm.. ik begin volgens mij in herhaling te vallen hier...)

Nu hebben we die 2/5 seconden niet echt objectief vastgesteld en is de opstarttijd maar een enkel aspect, maar als gegeven zou zijn dat Java 2,5 keer zo langzaam is als een native C/C++ applicatie, dan durf ik met recht te stellen dat Java traag is. Inderdaad is C/C++ code ook al snel 2,5 keer zo traag als pure assembly, maar feit is dat applicaties geschreven in assembly niet gangbaar zijn. Bij specifieke toepassingsgebieden van assembly is inderdaad ook bekend dat C/C++ traag is, vandaar dat op beperkte schaal algoritmen ook in assembly geschreven worden om een performance winst te behalen.

En deze zelfde vergelijking gaat op voor Java. Voor het grootste deel van de applicaties is Java snel genoeg, heb je voor specifieke onderdelen veel perfomance nodig schrijf dan dat stuk in C/C++.

[.oisyn]

PommeFritz schreef op 05 May 2003 @ 23:51:
.oisyn: kijk eens aan: http://java.sun.com/j2se/1.4.1/docs/guide/nio/index.html ...
(jdk 1.4+)

ik vind daar alleen memory mapped files (waarvan ik idd niet wist dat ze er waren, dat scheelt dus weer ). Maar ik zie nog steeds niet dingen als overlapped read/writes en synchronisatiefunctionaliteit.

Een simpele testcase dan maar: ik heb 3 open Sockets, en er moet gewacht worden tot er op een van die sockets data binnen komt. Ook moet het wachten van buitenaf geannuleerd kunnen worden. Hoe implementeer ik dat in Java met maar 1 thread?

Onder unix, linux en windows kan dat heel gemakkelijk. De windows implementatie:

C++:

void readThread (Socket * pSockets, int pNumSockets, HANDLE pInterruptEvent)
{
    std::vector<HANDLE> events (pNumSockets + 1);

    for (int i = 0; i < pNumSockets; i++)
    {
        events[i] = WSACreateEvent ();
        WSAEventSelect (pSockets[i], events[i], FD_READ);
    }

    events[pNumSockets] = pInterruptEvent;

    while (true)
    {
        DWORD r = WaitForMultipleObjects (&events.front (), events.size (), FALSE, INFINITE);

        if (r == WAIT_OBJECT_0 + pNumSockets) // interrupted
           break;

        else if (r >= WAIT_OBJECT_0 && r < WAIT_OBJECT_0 + pNumSockets)
        {
            // doe wat met pSockets[r - WAIT_OBJECT_0]
        }

        else
        {
            // error
        }
    }

    for (int i = 0; i < pNumSockets; i++)
    {
        WSAEventSelect (pSockets[i], NULL, 0);
        WSACloseEvent (events[i]);
    }
}

(ik kon hier ook select () gebruiken, wat ook op unix/linux werkt, maar dat vind ik persoonlijk wat cumbersome)

[curry684]

Overigens is WaitForMultipleObjects een bijzonder geil stuk functionaliteit dat ik nog op geen enkel ander platform in vergelijkbare vorm heb teruggevonden (ik had het hier onder OpenVMS ook graaaag gehad... )

[mbravenboer]

.oisyn: Een simpele testcase dan maar: ik heb 3 open Sockets, en er moet gewacht worden tot er op een van die sockets data binnen komt. Ook moet het wachten van buitenaf geannuleerd kunnen worden. Hoe implementeer ik dat in Java met maar 1 thread?

Er is wel degelijk non-blocking IO in de nieuwe IO API:

Een aardig overzicht van een aantal artikelen:
http://www.javaperformancetuning.com/tips/nio.shtml

Neem bijvoorbeeld deze:
http://www.onjava.com/pub.../06/topten.html?page=last
http://www.owlmountain.com/tutorials/NonBlockingIo.htm

[ Voor 17% gewijzigd door mbravenboer op 06-05-2003 10:56 ]

[PommeFritz]

curry684 schreef op 06 mei 2003 @ 10:44:
Overigens is WaitForMultipleObjects een bijzonder geil stuk functionaliteit dat ik nog op geen enkel ander platform in vergelijkbare vorm heb teruggevonden (ik had het hier onder OpenVMS ook graaaag gehad... )

Zolang het gaat om file descriptors (sockets, files, fifos, whatever) kun je select gebruiken daarvoor...

[.oisyn]

mbravenboer schreef op 06 May 2003 @ 10:54:
[...]

Er is wel degelijk non-blocking IO in de nieuwe IO API:

Een aardig overzicht van een aantal artikelen:
http://www.javaperformancetuning.com/tips/nio.shtml

Neem bijvoorbeeld deze:
http://www.onjava.com/pub.../06/topten.html?page=last
http://www.owlmountain.com/tutorials/NonBlockingIo.htm

ok, dan heb ik niets gezegd

PommeFritz schreef op 06 May 2003 @ 11:12:
[...]

Zolang het gaat om file descriptors (sockets, files, fifos, whatever) kun je select gebruiken daarvoor...

en nou nog kunnen combineren met events, mutexes, semaphores, etc.

[curry684]

.oisyn schreef op 06 May 2003 @ 11:56:
en nou nog kunnen combineren met events, mutexes, semaphores, etc.

En helaas is het alleen voor die objecten echt nuttig (evenals processen, threads, console input en met de Msg* calls ook windows messages).

[Verwijderd]

Ik heb een iets kortere reactie:
Zo en zo snelheid vergelijken tussen verschillende talen is onzinnig (en dan doel ik op wel of niet gc). Het grote voordeel van werken met een GC is uiteraard dat je je minder bezig hoeft te houden met memory leaks etc, ze treden immers minder snel op. En daar lever je wat snelheid voor in, maar dat is echt niet zo veel. Negen van de tien keer is het de programmeur die Java traag maakt.

Voorbeeld aangezien je met xml werkt, ik verwerk hier een xml bestand met zo'n 800000 tags in zo'n 20 seconden op een celeron 500... En dan gebruikt java slechts 7MB ram...

[hobbit_be]

mark: SAX waarschijnlijk? Bij ons moet de parsed Tree in memory zitten want die XML beschrijft de app - ie dus hij kan in het document all over the place geraken dan is SAX geen optie meer (ie XPath). Zoals ik ook al zei is het parsen zelf niet traag - maar wat Xindice doet blijft een raadsel (zeker omdat dit een server-app is)... we hebben mischien 5000-6000 tags, maar die doen wel veel: ie dynamic classes, smart parsing (ie enzovoorts)...

[.oisyn]

Verwijderd schreef op 06 May 2003 @ 13:37:
Ik heb een iets kortere reactie:
Zo en zo snelheid vergelijken tussen verschillende talen is onzinnig (en dan doel ik op wel of niet gc). Het grote voordeel van werken met een GC is uiteraard dat je je minder bezig hoeft te houden met memory leaks etc, ze treden immers minder snel op. En daar lever je wat snelheid voor in, maar dat is echt niet zo veel. Negen van de tien keer is het de programmeur die Java traag maakt.

Voorbeeld aangezien je met xml werkt, ik verwerk hier een xml bestand met zo'n 800000 tags in zo'n 20 seconden op een celeron 500... En dan gebruikt java slechts 7MB ram...

ik weet niet of er gevoelige info in staat oid, maar kun je die eens zippen en naar me toe mailen? Dan haal ik 'm door mijn eigen niet-volledig-aan-de-XML-standaard-conforme XML parser die ik in een half middagje in C++ heb geschreven (waar volgens mij geen delete statement in voor komt, en toch leakt ie geen memory. Hoezo, GC nodig? Destructors heersen )

[Soultaker]

Verwijderd schreef op 06 mei 2003 @ 13:37:
Ik heb een iets kortere reactie:
Zo en zo snelheid vergelijken tussen verschillende talen is onzinnig (en dan doel ik op wel of niet gc). Het grote voordeel van werken met een GC is uiteraard dat je je minder bezig hoeft te houden met memory leaks etc, ze treden immers minder snel op. En daar lever je wat snelheid voor in, maar dat is echt niet zo veel. Negen van de tien keer is het de programmeur die Java traag maakt.

Nee hoor, ook als je je best doet om netjes te programmeren is je Java applicatie traag. Dat blijkt wel uit het feit dat ook commercieel ontwikkelde applicaties (JBuilder ) aan dit probleem leiden.

Voorbeeld aangezien je met xml werkt, ik verwerk hier een xml bestand met zo'n 800000 tags in zo'n 20 seconden op een celeron 500... En dan gebruikt java slechts 7MB ram...

Hmm, 800.000 tags in 20 seconden vind ik nog niet heel impressive, maar goed, ik heb even geen vergelijkingsmateriaal. Welke parser gebruik je daar dan bij? En is die niet toevallig native geïmplementeerd in C of C++?

[Soultaker]

Verwijderd schreef op 06 mei 2003 @ 08:37:
Ik zeg toch ook nergens dat Java sneller of even snel is dan C/C++ code. En zoals ik ook al gezegd heb bij grote client apps is het best merkbaar dat het minder responsive is dan een native applicatie. Maar alleen omdat C/C++ sneller is maakt Java niet ineens traag. Je gaat er zo'n beetje van uit dat Java per definitie slecht presteert en altijd merkbaar traag is.

Dat is exact mijn punt, ja: een goede Java applicatie is altijd (laten we zeggen, in meer dan 75% van de gevallen) merkbaar trager (laten we zeggen, 50% of meer) dan een goede C/C++ applicatie. Dat is een beetje uit de lucht gegrepen door mij, want ik heb er geen exacte statistieken bij, maar het lijkt me een aardige veronderstelling. Als die veronderstelling waarheid blijkt, dan vind ik de stellin dat Java traag is ten opzichte van gangbare applicaties ook redelijk gerechtvaardigd. Dat aan C/C++ andere nadelen kleven (wat ik niet ontken) heeft daar verder niets mee te maken.

De rest van je reactie wilde ik even achterwege laten, aangezien daar eigenlijk niets in staat waarmee ik het oneens ben.

[Verwijderd]

Soultaker schreef op 06 May 2003 @ 16:29:
Dat is exact mijn punt, ja: een goede Java applicatie is altijd (laten we zeggen, in meer dan 75% van de gevallen) merkbaar trager (laten we zeggen, 50% of meer) dan een goede C/C++ applicatie. Dat is een beetje uit de lucht gegrepen door mij, want ik heb er geen exacte statistieken bij, maar het lijkt me een aardige veronderstelling. Als die veronderstelling waarheid blijkt, dan vind ik de stellin dat Java traag is ten opzichte van gangbare applicaties ook redelijk gerechtvaardigd.

Tja valt eigenlijk weinig op te antwoorden. Ik ben het met je eens dat client applicaties het imago van Java niet veel goed doet (uitzonderingen zoals JEdit daarbuiten gelaten). En ik moet helaas ook toegeven dat grote client/swing applicaties achter blijven bij grote native applicaties, daar valt weinig tegen in te brengen. Swing snel en responsive krijgen is erg lastig, maar zeker niet onmogelijk (nogmaals kijk maar eens naar JEdit). En ik ben het met je eens dat veel swing gebaseerde gui's merkbaar trager zijn.

Maar (er is altijd een maar), ik vind nog steeds niet dat je de performance van een GUI framework als uiteindelijke conclusie moet nemen dat het gehele java platform traag en sloom is.

De rest van je reactie wilde ik even achterwege laten, aangezien daar eigenlijk niets in staat waarmee ik het oneens ben.

We komer der nog wel uit

[Verwijderd]

Nou onder OS/2 draait java even snel als de rest hoor :-)

[machiel]

Even een vraagje, heb je (hobbit_be) de nieuwe jdk 1.4.2 al geprobeerd? Die moet een snellere opstartijd hebben?

Als snelheid een groot probleem is zou je de VM van IBM eens moeten bekijken, ik heb daar zelf helaas geen ervaring mee. Wat men niet moet vergeten is dat de JVM geen integraal onderdeel is van Java. Java kan je ook native compileren en in dat geval is het (in simpele gevallen) net zo snel als C++. De taal op zich is dus niet het probleem, GC is niet perse slomer dan C++ MM. En in de VM valt inderdaad veel te verbeteren, en laat die nou volledig inwisselbaar zijn! Ruimte voor verbetering dus

[hobbit_be]

ja we werken met 1.4.2 en naar native compilen tja datzou kunnen... moet je daar dan GCC voor bebruiken?

[MSalters]

curry684 schreef op 05 May 2003 @ 21:17:
[ 400Mb memory leak ]
Doe je het ook principieel terwijl je het weet? Terwijl een simpele delete je in de toekomst problemen kan schelen als die 400Mb plots wel vaker nodig is?

De "simpele" delete kostte me 75% van de totale runtime van het programma (volgens profiler en debug prints), de 400Mb was sowieso vaker nodig maar je startte het programma simpelweg opnieuw op.

Natuurlijk kan ik dit oplossen, ware het niet dat dit economisch niet haalbaar is.

[curry684]

Voor zo'n geval kan ik het nog wel begrijpen, maar het is een unieke case. Helaas doet men het hier ook met 24/7 servers voor fab-automatisering....