[java] file read... Waarom veel sneller?

[Verwijderd]

Ik heb een methode geschreven om een file in te lezen.
Het gaat om een plain text file.

Kan iemand mij vertellen waarom precies methode 1, zo'n 10x sneller is dan methode 2?

voorbeeld 1

code:

    public void setFileMessage(String file_name) {
        StringBuffer msg = new StringBuffer("");
        try {
            BufferedReader in = new BufferedReader(new FileReader(file_name));
            String s = new String();
            while ((s = in.readLine()) != null) {
                msg.append(s + "\n");
            }
            in.close();
        } catch (IOException e) {
            Debugger.printMessage("IOError occured during read of textfile", Debugger.ERROR);
        }
        this.message = msg.toString();
    }

voorbeeld 2

code:

public void setFileMessage(String file_name) {
      String msg = "";

        try {
            BufferedReader in = new BufferedReader(new FileReader(file_name));
            String s = new String();
            while ((s = in.readLine()) != null) {
                   msg += s + "\n";
            }
            in.close();
     } catch (IOException e) {
            Debugger.printMessage("IOError occured during read of textfile", Debugger.ERROR);
        }
         this.message = msg;
}

Bedankt!

[ Voor 0% gewijzigd door Verwijderd op 05-09-2002 15:48 . Reden: code recht(er) gezet ]

[whoami]

Het verschil zit em er gewoon in dat je de ene keer de append functie oproept en de andere keer de += operator?

Misschien dat je in de Help meer informatie krijgt over de werking van die append functie ofzow...

[Alarmnummer]

Je loopt steeds strings aan te maken bij het 2e voorbeeld en bij het eerste gebruik je een stringbuffer. Je moet er rekenign mee houden dat een string immutable is. Dus s=s+"..." geeft dus een nieuwe string!!

[edit]
volgens mij moet de 1e veel sneller zijn dan de 2e.. dit is wel een beetje eigenaardig.

[Verwijderd]

Alarmnummer schreef op 05 september 2002 @ 15:46:
Je loopt steeds strings aan te maken bij het 2e voorbeeld en bij het eerste gebruik je een stringbuffer. Je moet er rekenign mee houden dat een string immutable is. Dus s=s+"..." geeft dus een nieuwe string!!

Ik begrijp dat ik telkens nieuwe strings aanmaak.
Maar moet dat zo'n groot probleem zijn? Wat doet een StringBuffer dan precies anders wat het zoveel sneller maakt?

[Alarmnummer]

Voor een stringbuffer worden er niet iedere keer onnodig nieuwe objecten aangemaakt als hij gaat groeien. Een string die kan niet groeien, dus als je zegt s=s+"..."; dan maak je iedere keer een nieuw object aan. In een stringbuffer zit gewoon een dikke array met chars, en als je die in het begin groot genoeg maakt, dan zul je die array niet hoeven te vervangen, en daarom is het dus veel sneller.

[momania]

Verwijderd schreef op 05 september 2002 @ 15:47:
[...]


Ik begrijp dat ik telkens nieuwe strings aanmaak.
Maar moet dat zo'n groot probleem zijn? Wat doet een StringBuffer dan precies anders wat het zoveel sneller maakt?

Precies was Alarmnummer al zei:

Gebruik je s+=tmp+.... dan staat daar eigenlijk s=s+tmp+... en wil dus zeggen
dat s iedere keer opnieuw geinitialiseerd wordt... (Obect wordt iedere keer
weggegooid en nieuw aangemaakt)

Bij een StringBuffer gebeurt dit niet en win je dus je tijd door het niet steeds
hoeven aanmaken van objecten...

edit:
Alarmnummer was me al weer voor zag ik

[Dash2in1]

Kan iemand mij vertellen waarom precies methode 1, zo'n 10x sneller is dan methode 2?

[edit]
volgens mij moet de 1e veel sneller zijn dan de 2e.. dit is wel een beetje eigenaardig.

klopt toch ook??

[LordLarry]

Dat is geen groot probleem, maar maakt het wel langzamer.

Er moet een nieuw stuk geheugen gereserveerd worden dat groot genoeg is, daar moeten beide strings achter elkaar in gekopieerd worden en dan wordt de oude weggegooid. Dat kost gewoon tijd.

Een StringBuffer doet het iets anders waardoor het sneller is. Ik weet het niet precies hoe die het doet, maar ik gok dat ie een linked list bijhoud van strings en pas achterelkaar plakt als je er om vraagt.

[Alarmnummer]

Dash2in1 schreef op 05 september 2002 @ 15:54:
[...]


[...]

klopt toch ook??

Volgens mij heeft hij iets aangepast of ik heb niet goed gekeken, maar het klopt nu inderdaad wel

[Alarmnummer]

LordLarry schreef op 05 september 2002 @ 15:55:
Een StringBuffer doet het iets anders waardoor het sneller is. Ik weet het niet precies hoe die het doet, maar ik gok dat ie een linked list bijhoud van strings en pas achterelkaar plakt als je er om vraagt.

Gewoon een array van chars.

code:

public final class StringBuffer
    implements java.io.Serializable, CharSequence
{
    /**
     * The value is used for character storage.
     * 
     * @serial
     */
    private char value[];

    /** 
     * The count is the number of characters in the buffer.
     * 
     * @serial
     */
    private int count;
    ....

[LordLarry]

En dan? Ik ben geen Java goeroe, maar dit zegt nog niet zo veel
Reserveerd ie een hele grote buffer ofzo?

[Alarmnummer]

Om dat code meestal meer zegt

code:

  /**
     * Constructs a string buffer with no characters in it and an 
     * initial capacity of 16 characters. 
     */
    public StringBuffer() {
    this(16);
    }

    /**
     * Constructs a string buffer with no characters in it and an 
     * initial capacity specified by the <code>length</code> argument. 
     *
     * @param      length   the initial capacity.
     * @exception  NegativeArraySizeException  if the <code>length</code>
     *               argument is less than <code>0</code>.
     */
    public StringBuffer(int length) {
    value = new char[length];
    shared = false;
    }

    /**
     * Constructs a string buffer so that it represents the same 
     * sequence of characters as the string argument; in other
     * words, the initial contents of the string buffer is a copy of the 
     * argument string. The initial capacity of the string buffer is 
     * <code>16</code> plus the length of the string argument. 
     *
     * @param   str   the initial contents of the buffer.
     * @exception NullPointerException if <code>str</code> is <code>null</code>
     */
    public StringBuffer(String str) {
    this(str.length() + 16);
    append(str);
    }

[LordLarry]

Dus het reserverd elke keer een groot stuk geheugen in 1x ipv elke keer precies genoeg. Als het dan te groot wordt voor het geheugen dat er gereserveerd is pakt het een nieuw en nog groter stuk geheugen.

Dankje voor de code Alarmnummer

[TheOneLLama]

LordLarry schreef op 05 september 2002 @ 15:55:
Een StringBuffer doet het iets anders waardoor het sneller is. Ik weet het niet precies hoe die het doet, maar ik gok dat ie een linked list bijhoud van strings en pas achterelkaar plakt als je er om vraagt.

Je zou een Stringbuffer kunnen zien als een soort vector van char's.. maar het is gewoon in de source te lezen natuurlijk

[Glimi]

Source te vinden in je j2sdk directory in src.zip, in de map java/util in de file StringBuffer

[LordLarry]

Bedankt, natuurlijk kan dat, ben er te lui voor wat java betreft

Een vector van chars is het niet echt hoop ik, dat zou meer slaan op een string. Of groeit een vector ook met grote stappen tegelijk?

[Alarmnummer]

yep.. in een vector zit ook gewoon een array...

maar ik snap niet dat er nog verder gepraat wordt over hoe het bij een StringBuffer is gedaan. Zoals je in de code kan zien (zie mijn replies) zit er gewoon een array van chars in, met een huidige lengte!

[Verwijderd]

Ik vraag me net af... waarom duwen ze die functionaliteit niet gewoon in de String? Los van hoe dat je het zou moeten oplossen met de operator zou het geen probleem moeten zijn, toch? Kunnen ze meteen die vreemde final modifier bij public class String weghalen, want die staat er IMHO ook alleen maar omdat ze van String zo'n rotzooi hebben gemaakt dat ze bang zijn dat iemand hem gaat extenden...

...


Sorry, deadline > _echt_ te veel Java > weinig slaap >

[.oisyn]

Verwijderd schreef op 06 september 2002 @ 03:28:
Ik vraag me net af... waarom duwen ze die functionaliteit niet gewoon in de String?

omdat java een const specifier mist

voorbeeld:

Java:

class Blaat
{
    private String naam;

    public String getNaam ()
    {
         return naam;
    }
}

class Woei
{
    public doeIetsMetBlaat (Blaat b)
    {
        String s = b.getNaam ();
        s += "34";
    }
}

Als de functionaliteit in String zou zitten, dus dat je met += een stuk erachter aan kunt plakken (de String is dan mutable), dan kun je heel fijn gegevens van een bepaald object wijzigen. Want na Woei.doeIetsMetBlaat () is de naam van de Blaat die je meegaf veranderd. Dat kan toch nauwelijks de bedoeling zijn