[Java] Collection >> JTable

[vinnux]

Na heel wat geploeter met Bean Managed Persistency (BMP)is het gelukt om een java.Util.Collection terug te krijgen met laten we zegen kandidaten. Nou wil ik deze lijst laten tonen in een JTable. Alleen dat gaat dus een beetje heel erg traag met onderstaande code. Heeft iemand een beter id ?

code:

KandidatuurTestClient client = new KandidatuurTestClient();
     Collection  kandidatuurCollection = client.findAll();
     Iterator    kandidatuurCollectionIterator =  kandidatuurCollection.iterator();
     Vector kandidatuurVector = new Vector(900);
     while (kandidatuurCollectionIterator.hasNext()){
    try{
     Kandidatuur  kandidaat = (Kandidatuur) PortableRemoteObject.narrow(kandidatuurCollectionIterator.next(),Kandidatuur.class);
     Object [] kandidaatString = new Object[4];
     kandidaatString[0] = new Integer(kandidaat.getKandidatuurId());
     kandidaatString[1] = kandidaat.getNaam();
     kandidaatString[2] =new Integer(kandidaat.getLeeftijd());
     kandidaatString[3] = kandidaat.getHomepage();
     kandidatuurVector.add( kandidaat);
     System.out.println(kandidaat.getKandidatuurId());;
    } catch (Exception x) {
      x.printStackTrace();
    }
     }
    Vector kandidatuurVectorNames = new Vector();
    kandidatuurVectorNames.add("KandidatuurId");
    kandidatuurVectorNames.add("Naam");
    kandidatuurVectorNames.add("Leeftijd");
    kandidatuurVectorNames.add("Homepage");

Of te wel hoe krijg ik een Collection zo snel mogelijk in een JTable

[Alarmnummer]

Als ik een resulset van 1500 records in een JTable zet, ben ik nagenoeg geen tijd kwijt. Misschien dat die narrow functie de bottelneck is. Probeer eens die regel te skippen en dan de inhoud te vullen van kandidaat met onzin. Dan weet je in ieder geval waar het probleem zit.

[Alarmnummer]

Misschien dat het ook verstandig is om die try catch buiten de lus te plaatsen. Ik neem aan dat het als het 1 keer is fout gegaan, dat het blijft fout gaan. Dus dit is niet echt een logische constructie dan.

[KinkyClown]

1) Het is geen "Self Persitent Entity Beans" maar Bean Managed Persistency (BMP).

2) Maak gebruik van de Collections framework i.p.v. Vectors. Oftewel ArrayList i.p.v. Vector. Vector is synchornized en dat is 100 keer trager dan ArrayList.

3) Maak gebruik van een TableModel i.p.v. een tabel aan te maken en deze te vullen. Kijk in de standaard Sun tutorial hoe je dat doet. "How to use JTable" heet deze geloof ik.

[vinnux]

Op woensdag 03 april 2002 12:53 schreef Alarmnummer het volgende:
Als ik een resulset van 1500 records in een JTable zet, ben ik nagenoeg geen tijd kwijt. Misschien dat die narrow functie de bottelneck is. Probeer eens die regel te skippen en dan de inhoud te vullen van kandidaat met onzin. Dan weet je in ieder geval waar het probleem zit.

Aangezien ik met EJB's werkt en dat weer werkt met RMI kan ik geen resultsets gebruiken omdat dat geen seriliziable objects zijn.
Het is een zogenaamde gedistribueerde applicatie. Waarvan ik de Home interface aanspreek. Zie http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Overview3.html#65425

[Alarmnummer]

Ik vraag ook niet om het ander aan te pakken, maar probeer je te helpen met het achterhalen van de bottleneck. Je moet namelijk eerst weten wat er langzaam is om er wat aan te doen.

ps: waarom maak je van te voren een vector van 900 aan?? weet je de size al ofzo?

[Alarmnummer]

Op woensdag 03 april 2002 13:00 schreef KinkyClown het volgende:
2) Maak gebruik van de Collections framework i.p.v. Vectors. Oftewel ArrayList i.p.v. Vector. Vector is synchornized en dat is 100 keer trager dan ArrayList.

Onzin. Met de huidige vm maakt synchronisatie niet zoveel meer uit. Er zijn nog wel een paar testen tussen vectoren/arraylisten en hashtables/hashmaps en daaruit bleek dat het performance verschil heel klein is. (in de geest van een aantal procenten).

en.. vector is onderdeel van het Collection Framework!! dus wat je zegt is echt onzin.

[yrew]

uhm misschien een stomme opmerking hoor. Maar haal je misschien 10 velden op terwijl je er maar 2 wil laten zien.

[vinnux]

Op woensdag 03 april 2002 13:03 schreef Alarmnummer het volgende:
Ik vraag ook niet om het ander aan te pakken, maar probeer je te helpen met het achterhalen van de bottleneck. Je moet namelijk eerst weten wat er langzaam is om er wat aan te doen.

De bottleneck zit in het narowen en het daarna converteren naar OBject array en dan in een Vector plaatsen. ff testen.

ps: waarom maak je van te voren een vector van 900 aan?? weet je de size al ofzo?

Ja die weet ik toevallig maar die kan ik ook ophalen met java.util.Collecten <name>.size()

[vinnux]

Op woensdag 03 april 2002 13:16 schreef yrew het volgende:
uhm misschien een stomme opmerking hoor. Maar haal je misschien 10 velden op terwijl je er maar 2 wil laten zien.

Graag laat ik ze allemaal zien

[yrew]

Als je ze laat zien selecteer je ze uit een database. Je laat nu alleen ID NAAM LEEFTIJD HOMEPAGE zien. Als je hiernaast ook nog KLAS ROOSTER ETC ETC opvraagt kunnen je objecten erg groot worden en zo xtra performance eisen.

Ik vind het handig om voor lijsten een apparte select op te nemen.

[vinnux]

Ik heb de code enigzins aangepast :

code:

KandidatuurTestClient client = new KandidatuurTestClient();
    Collection  kandidatuurCollection = client.findAll();
    int     size   = kandidatuurCollection.size();
    String [] [] values = new String [size] [4];
    Object [] kandidatuurObjects = kandidatuurCollection.toArray();
    kandidatuurCollection = null;
    System.gc();
  
    Kandidatuur  kandidaat = null;
    try {
    for (int nr = 0 ; nr < size ; nr ++){
      kandidaat = (Kandidatuur) PortableRemoteObject.narrow(kandidatuurObjects[nr],Kandidatuur.class);
      values [nr] [0] =""+kandidaat.getKandidatuurId();;
      values [nr] [1] =kandidaat.getNaam();
      values [nr] [2] =""+kandidaat.getLeeftijd();
      values [nr] [3] =""+kandidaat.getHomepage();;
    }
    } catch (Exception x) {
    x.printStackTrace();
    }
   String [] names = {"KandidatuurId","Naam","Leeftijd","Homepage"};

Hier wat testtijden voor het traceren van de bottleneck :

code:

Creating client took : 4969ms
Retrieving the kandidatuur collection took : 3000ms
Converting the Collection to an Object[] took : 0ms
Narrowing the objects took : 331ms
Putting them in the array took : 51998ms

Of te wel het volgende stuk code vreet de meeste tijd !

code:

values [nr] [0] =""+kandidaat.getKandidatuurId();;
      values [nr] [1] =kandidaat.getNaam();
      values [nr] [2] =""+kandidaat.getLeeftijd();
      values [nr] [3] =""+kandidaat.getHomepage();;

Maar wat is hiervan langzaam ?

[Scare360]

Op woensdag 03 april 2002 12:48 schreef vgouw het volgende:
Na heel wat geploeter met Bean Managed Persistency (BMP)is het gelukt om een java.Util.Collection terug te krijgen met laten we zegen kandidaten. Nou wil ik deze lijst laten tonen in een JTable. Alleen dat gaat dus een beetje heel erg traag met onderstaande code. Heeft iemand een beter id ?

code:

KandidatuurTestClient client = new KandidatuurTestClient();
     Collection  kandidatuurCollection = client.findAll();
     Iterator    kandidatuurCollectionIterator =  kandidatuurCollection.iterator();
     Vector kandidatuurVector = new Vector(900);
     while (kandidatuurCollectionIterator.hasNext()){
    try{
     Kandidatuur  kandidaat = (Kandidatuur) PortableRemoteObject.narrow(kandidatuurCollectionIterator.next(),Kandidatuur.class);
     Object [] kandidaatString = new Object[4];
     kandidaatString[0] = new Integer(kandidaat.getKandidatuurId());
     kandidaatString[1] = kandidaat.getNaam();
     kandidaatString[2] =new Integer(kandidaat.getLeeftijd());
     kandidaatString[3] = kandidaat.getHomepage();
     kandidatuurVector.add( kandidaat);
     System.out.println(kandidaat.getKandidatuurId());;
    } catch (Exception x) {
      x.printStackTrace();
    }
     }
    Vector kandidatuurVectorNames = new Vector();
    kandidatuurVectorNames.add("KandidatuurId");
    kandidatuurVectorNames.add("Naam");
    kandidatuurVectorNames.add("Leeftijd");
    kandidatuurVectorNames.add("Homepage");

Of te wel hoe krijg ik een Collection zo snel mogelijk in een JTable

Wellicht een 234 tree gebruiken om je kanditatuur datastructuur op poten te zetten.

[Alarmnummer]

Je gaat iedere keer een bepaald elemetn uit die array ophalen (en dat kost tijd) Je kan beter dat element 1 keer ophalen en ff in een temp variable plaatsen.

code:

String[] banaan = values[nr];
banaan[0] =""+kandidaat.getKandidatuurId();;
banaan[1] =kandidaat.getNaam();
banaan[2] =""+kandidaat.getLeeftijd();
banaan[3] =""+kandidaat.getHomepage();;

En ik vind het niet geloofwaardig dat het laatste stuk de meeste tijd kost.

[vinnux]

Op woensdag 03 april 2002 13:36 schreef paulgielens het volgende:

[..]

Wellicht een 234 tree gebruiken om je kanditatuur datastructuur op poten te zetten.

Graag iets meer uitleg en motivatie.

[vinnux]

Op woensdag 03 april 2002 13:38 schreef Alarmnummer het volgende:
En ik vind het niet geloofwaardig dat het laatste stuk de meeste tijd kost.

Dit is de code waarmee getest is :

code:

long startTime = System.currentTimeMillis();
    KandidatuurTestClient client = new KandidatuurTestClient();
    System.out.println("Creating client took : "+(System.currentTimeMillis()-startTime)+"ms");
    startTime = System.currentTimeMillis();
    Collection  kandidatuurCollection = client.findAll();
    System.out.println("Retrieving teh kandidatuur collection took : "+(System.currentTimeMillis()-startTime)+"ms");
    int     size   = kandidatuurCollection.size();
    String [] [] values = new String [size] [4];
    startTime = System.currentTimeMillis();
    Object [] kandidatuurObjects = kandidatuurCollection.toArray();
    System.out.println("Converting the Collection to an Object[] took : "+(System.currentTimeMillis()-startTime)+"ms");
    kandidatuurCollection = null;
    System.gc();

    long portime = 0;
    long parsetime = 0;

    Kandidatuur  kandidaat = null;
    try {
    for (int nr = 0 ; nr < size ; nr ++){
      startTime = System.currentTimeMillis();
      kandidaat = (Kandidatuur) PortableRemoteObject.narrow(kandidatuurObjects[nr],Kandidatuur.class);
      portime += System.currentTimeMillis() - startTime;
      startTime = System.currentTimeMillis();
      values [nr] [0] =""+kandidaat.getKandidatuurId();;
      values [nr] [1] =kandidaat.getNaam();
      values [nr] [2] =""+kandidaat.getLeeftijd();
      values [nr] [3] =kandidaat.getHomepage();;
      parsetime += System.currentTimeMillis() - startTime;
    }
    } catch (Exception x) {
    x.printStackTrace();
    }
    System.out.println("Narrowing the objects took : "+portime+"ms");
    System.out.println("Putting them in the array took : "+parsetime+"ms");

Dus geloof het maar gewoon.

[Scare360]

Op woensdag 03 april 2002 13:39 schreef vgouw het volgende:

[..]

Graag iets meer uitleg en motivatie.

234 -> niet wetende grootte van structuur, snel zoeken aangezien de boom geballanceerd is... de ideale structuur voor dit probleem!

[vinnux]

Op woensdag 03 april 2002 13:49 schreef paulgielens het volgende:

[..]

234 -> niet wetende grootte van structuur, snel zoeken aangezien de boom geballanceerd is... de ideale structuur voor dit probleem!

Ik heb alleen maar een simpel lijstje van kandidaten dat ik wil tonen. Er zijn verder geen links die op dit moment relevenat is.
En hoe ziet dat 234 er concreet uit, voorbeeldje

[Alarmnummer]

Op woensdag 03 april 2002 13:49 schreef paulgielens het volgende:

[..]

234 -> niet wetende grootte van structuur, snel zoeken aangezien de boom geballanceerd is... de ideale structuur voor dit probleem!

de vraag is of hij wil zoeken...

als hij wil zoeken dan vraag ik me af of een boom nou zo geschikt is want voor een binaire boom met n elementen ben je log(n) zoekacties kwijt. Maar voor een hash structuur ben je een constante tijd kwijt. Dus als je een hashcode kan bepalen dan zou ik dus gewoon gaan voor een hashmap ipv tree.

maarja.. volgens mij is het probleem helemaal niet dat hij wil zoeken. Zijn ophaal routine 'narrow' ed die zijn zo langzaam. Ik vraag me dus eerlijk gezegd wat 234 tree (waar ik nog nooit van heb gehoord) voor toegevoegde waarde aan dit topic geeft.

[vinnux]

Ik heb de oorzaak gevonden en die oorzaak zit in de Bean.
Wanneer ik de volgende code wordt uitgevoerd :

code:

 values [nr] [0] =""+kandidaat.getKandidatuurId();;
      values [nr] [1] =kandidaat.getNaam();
      values [nr] [2] =""+kandidaat.getLeeftijd();
      values [nr] [3] =kandidaat.getHomepage();;*/

Wordt er elke keer een call gedaan naar de Home interface van kandidaat. Deze zal vervolgens met RMI deze methode invoken in de Bean (Aan de server kant dus). In mijn geval betekent dat dat ie dat 930 * 4 = 3720 keer moet doen.
Dat moet vervolgens weer geserialized worden en terug gestuurd worden. Geheid zal het een en ander een CORBA objecten rondgeslingerd worden.
Onderstaande code wordt namelijk in 340ms uitgevoerd :

code:

  values [nr] [0] ="dd";
      values [nr] [1] ="fdsdfsdfsd";
      values [nr] [2] ="fdsdfsdfsd";
      values [nr] [3] ="fdsdfsdfsd";

Conclusie :
BMP zijn leuk dingen om een rij te editen, maar om ze allemaal te tonen is het niet nuttig, of je moet een supe netwerk computer + netwerk hebben.

Ja dan maar mijn Bean aanpassem

[KinkyClown]

Ik zie nu wat het probleem is. Je hebt dan wel een collection gebruikt maar je narrowed elke uitkomst waaraan ik kan afleiden dat je BMP niet helemaal handig is: je creeërd voor elke record 1 entity bean die narrow je en haal je de gegevens van op. Dit werkt belastend en traag. Je kan beter een BMP boon maken die een collection maakt en deze gewoon in 1 keer teruggeeft.

[KinkyClown]

Op woensdag 03 april 2002 14:05 schreef vgouw het volgende:
Ik heb de oorzaak gevonden en die oorzaak zit in de Bean.
Wanneer ik de volgende code wordt uitgevoerd :

code:

 values [nr] [0] =""+kandidaat.getKandidatuurId();;
      values [nr] [1] =kandidaat.getNaam();
      values [nr] [2] =""+kandidaat.getLeeftijd();
      values [nr] [3] =kandidaat.getHomepage();;*/

Wordt er elke keer een call gedaan naar de Home interface van kandidaat. Deze zal vervolgens met RMI deze methode invoken in de Bean (Aan de server kant dus). In mijn geval betekent dat dat ie dat 930 * 4 = 3720 keer moet doen.
Dat moet vervolgens weer geserialized worden en terug gestuurd worden. Geheid zal het een en ander een CORBA objecten rondgeslingerd worden.
Onderstaande code wordt namelijk in 340ms uitgevoerd :

code:

  values [nr] [0] ="dd";
      values [nr] [1] ="fdsdfsdfsd";
      values [nr] [2] ="fdsdfsdfsd";
      values [nr] [3] ="fdsdfsdfsd";

Conclusie :
BMP zijn leuk dingen om een rij te editen, maar om ze allemaal te tonen is het niet nuttig, of je moet een supe netwerk computer + netwerk hebben.

Ja dan maar mijn Bean aanpassem

Je was me net voor

[vinnux]

Op woensdag 03 april 2002 14:05 schreef KinkyClown het volgende:
Ik zie nu wat het probleem is. Je hebt dan wel een collection gebruikt maar je narrowed elke uitkomst waaraan ik kan afleiden dat je BMP niet helemaal handig is: je creeërd voor elke record 1 entity bean die narrow je en haal je de gegevens van op. Dit werkt belastend en traag. Je kan beter een BMP boon maken die een collection maakt en deze gewoon in 1 keer teruggeeft.

De tijd zit hem niet in het narrowen dat kost nog geen 300ms, maar in die RMI calls die ik uitvoer (kandidaat.getNaam(), etc)

Ja die gegenereerde beans van JBuilder 6 zijn ook niet alles !

[Scare360]

Op woensdag 03 april 2002 13:51 schreef vgouw het volgende:

[..]

Ik heb alleen maar een simpel lijstje van kandidaten dat ik wil tonen. Er zijn verder geen links die op dit moment relevenat is.
En hoe ziet dat 234 er concreet uit, voorbeeldje

http://www.cs.cornell.edu/Courses/cs211/2000fa/materials/Nov09%20BSTs%20and%20Balanced%20Trees.pdf

[Bobco]

Op woensdag 03 april 2002 14:05 schreef vgouw het volgende:
Conclusie :
BMP zijn leuk dingen om een rij te editen, maar om ze allemaal te tonen is het niet nuttig, of je moet een supe netwerk computer + netwerk hebben.
Ja dan maar mijn Bean aanpassem

Dit verhaal heb ik ook wel eens van de kant van Oracle gehoord: BMP is leuk voor kleine hoeveelheden data, maar als het alleen gaat om retrieval: gebruik gewoon een Session Bean en laat die het werk maar doen via JDBC. BMP heeft nogal wat overhead, zoals je nu zelf gezien hebt

[PommeFritz]

Ipv elk veld van de Entity Bean op te halen met een
aparte method call, is het veel efficienter om met
zogenaamde Value Objects te werken.
Je stopt de hele state (=alle velden) van de EJB in
een value object (het "model") en je gebruikt maar
1 method call (getDetails() ofzo) die dan in 1 keer
dit model teruggeeft.

Het model is een doodnormale Java class.

Dit werkt ook andersom, om velden te updaten doe je
dat eerst "lokaal" via een model, die je vervolgens
met 1 method call in de EJB zet.

Zie http://java.sun.com/blueprints/patterns/j2ee_patterns/value_object/index.html

[KinkyClown]

Op woensdag 03 april 2002 14:17 schreef Bobco het volgende:

[..]

Dit verhaal heb ik ook wel eens van de kant van Oracle gehoord: BMP is leuk voor kleine hoeveelheden data, maar als het alleen gaat om retrieval: gebruik gewoon een Session Bean en laat die het werk maar doen via JDBC. BMP heeft nogal wat overhead, zoals je nu zelf gezien hebt

Volgens mij heb je de klok horen luiden maar weet je niet waar de klepel hangt.
BMP - Bean Managed Persistancy is wanneer je zelf een JDBC connectie maakt en de opslag / ophalen zelf regeld.
CMP - Container Managed Persistancy is wanneer je een simpele Entity bean maakt, de container (J2EE container) zal de gegevens voor je ophalen en wegzetten zoals aangegeven in de bijgeleverde XML (descriptor).
Dus: CMP is leuk voor de kleine hoeveelheden, BMP voor de grotere queries of complexe berekeningen zoals het gemiddelde berekenen van een paar duizend records.