String und char[] / String[] und Vector

[Corcovado]

Hallo
1. Ist das Arbeiten mit char[] schneller als mit String Objekten?
2. Sind String[] schneller als Vector Objekte?

 

[Roar]

1. ja, um ein paar ns/ms
2. ja, um ein paar ns/ms

edit: warum probierst du das nicht erinfach aus?

 

[Corcovado]

..war mir nich sicher. Ich ueberlege mir das da ich momentan ein paar 1000 Strings habe ob es besser ist eher einen Vector oder ein Array zu nehmen (da ich aber mom an der Grafik rumbastel und das hier nur mal so ne Idee war, wollte ich dazu mal so Eure Antworten hoeren) oder vielleicht gleich ein array von einem char[]?!?

Was wuerdet Ihr sagen, ab wievielen Eintraegen ca (zB von String Obj) in einen Vector es sinnvoller waere eher ein Array zu nehmen?

 

[Illuvatar]

wenns immer gleichviele sin is nen array sinnvoller sonst vector das hängt eigentl weiger von der größe ab

 

[bygones]

kann mir nicht vorstellen da in irgendeiner weise einen signifikanten Unterschied zu sehen.

Vector ansich ist auch nur ein Array mit Methoden drumrum - einzige was in verlangsamen würde ist dass alle Methoden synchronized sind... aber ansonsten... nö

 

[AlArenal]

@carcovado:

Erste Grundregel ist "make it work". Ich mache mir nicht unnötig Kopf um dolle Optimierungen, wenn ich noch gar nicht weiß, ob sie notwendig sind. So komme ich ja mit der Entwicklung nie ausm Quark.

 

[Roar]

@dbac: das was speicher verbraucht ist woh ldas array kopieren und wenn du 1000 strings hin und her kopieren muss kann sichdas shcon bemerkbar machen. @corcovado: wenn die anzahl strings in der größenordnung sind würde ich mir vielleicht eine eigene Listenmklasse schreibgen, die den array imerm um 500 elemente vergößert oder so wenn nötig...

 

[Wildcard]

@corcovado: wenn die anzahl strings in der größenordnung sind würde ich mir vielleicht eine eigene Listenmklasse schreibgen, die den array imerm um 500 elemente vergößert oder so wenn nötig...

ArrayList/Vector lassen sich im Konstruktor entsprechend konfigurieren, eine eigene Klasse ist daher unnötig.
Ich halte es für Blödsinn auf den Komfort von Strings und Collections aus Perofmancegründen zu verzichten.
Um Performance macht man sich idR nur bei String-Operationen, Zeichnen und komplexen Berechnungen Gedanken.

 

[Roar]

ArrayList/Vector lassen sich im Konstruktor entsprechend konfigurieren, eine eigene Klasse ist daher unnötig.

edit: ach, hab ja gesehen, dass man auch im konsutrktor von Vector sagen kann, um wie iele speicherstellen er das array vergrößern sol, damit hat sie die idee, ensureCapacity() zu überschreiben wohl erledigt

 

[Corcovado]

@Illuvator:

wenns immer gleichviele sin is nen array sinnvoller sonst vector das hängt eigentl weiger von der größe ab

tja, aber es ist doch sicherlich moeglich zu einem Array neuen Speicher dazu zuallokieren oder etwa nicht in Java - was anderes wird doch der Vektor auch nicht machen? Auch wenn ihn das eben daher auch teurer macht als ein Array?!

@deathbyaclown:

Vector ansich ist auch nur ein Array mit Methoden drumrum - einzige was in verlangsamen würde ist dass alle Methoden synchronized sind... aber ansonsten... nö

tja Array == Array, aber das "drumrum" (Object, Allokation, Iteratoren, etc) hat doch auch konstruktoren (=Speicherallokation), dh fuer mich es kostet also (wenn die Denkweise so auch bei Java richtig sein sollte)?

@AlArenal:

Erste Grundregel ist "make it work". Ich mache mir nicht unnötig Kopf um dolle Optimierungen, wenn ich noch gar nicht weiß, ob sie notwendig sind. So komme ich ja mit der Entwicklung nie ausm Quark.

Ok, make it work - was nun? Ich mach mir auch keinen Kopf ueber Optimierungen zu Projekten die nicht existieren, allerdings hab ich gerade ein Projekt und ueberlege das Ding zu Optimieren. Es gibt sicherlich einige andere, zunaechst naeherliegende Sachen - dabei bin ich grad, is aber nich das Thema hier - was mich hier interessiert ist, dass ich eher ueber die generelle Strategie nachdenke wie ich eine zentrale Datenstruktur etwa generell umstrukturieren sollte oder nicht. Das is wiederum etwas mehr Aufwand, daher wollte maln Paar Meinungen hoeren.

@Roar:

@dbac: das was speicher verbraucht ist woh ldas array kopieren und wenn du 1000 strings hin und her kopieren muss kann sichdas shcon bemerkbar machen. [/code]
...an interne Copycontruktoren hab ich noch gar nicht gedacht, sollte aber eigentlich kein grosses Problem bei meiner speziellen Sache darstellen.

@Roar die zweite:

@corcovado: wenn die anzahl strings in der größenordnung sind würde ich mir vielleicht eine eigene Listenmklasse schreibgen, die den array imerm um 500 elemente vergößert oder so wenn nötig...[/quote]
Das ist GENAU das was ich hier durchdiskutieren will. Danke! So aehnlich hab ichs mir auch vorgestellt, ich weiss nur eben nicht ob sich das schon rentiert bei einigen oder einigen 1000 Elementen oder ob das ueberhaupt was bringen koennte?

 

[Roar]

benutzt du im moment einen Vector ?
wenn ja initialisiere doch mal deinen Vector so: new Vector(1000, 500) oder entsprechend deinen größenordnungen und schau ob das schneller geht. einen großen utnerschied würde ich aber nich erwarten....

 

[Corcovado]

Gut danke, werd ich ausprobieren.

Ich hab bisher alles in einen Vektor von einem Vektor von String eingelesen, das war urlangsam (auf Pentium 2 und es gehoert eh nochmal generell ueberarbeitet).
Um das effektiver zu machen, wollte ich aber erst statt String schon mal mit double (kleingeschrieben) arbeiten fuer ein bestimmtes Segment, weil ich nun auch festgestellt hab, dass String in Double und dann rumrechnen (was ein Teil werden soll) aufwendig ist und das mit double schon nen Vorteil bringt.

Nun ueberleg ich halt ob ichs nich gleich ganz auch statt (zumindest einem der beiden) Vektor, mit Arrays versuchen sollte, evtl auch statt String eben char[] - wie gesagt noch n Bisschen hin. Danke trotzdem schon mal, ich denke ich werd vielleicht doch mal beides implementieren und nachmessen.

 

[bygones]

wie schon erwähnt - man kann dem Konstruktor die Größe des Arrays für den Vector angeben. Das neu allozieren ist nicht das Problem des Vectors, sondern das hat man auch bei einem normalen Array !

tja Array == Array, aber das "drumrum" (Object, Allokation, Iteratoren, etc) hat doch auch konstruktoren (=Speicherallokation), dh fuer mich es kostet also (wenn die Denkweise so auch bei Java richtig sein sollte)?

wie ?
Object hat erstmal nichts damit zu tun - Allokation hast du überall - Iterator wird beim erstellen gar nicht verwendet. Nur wenn du per iterator() einen anforderst....

wie gesagt - Vector ist eine "Wrapper" Klasse für Arrays. mehr nicht.

ich stimme aber auch Wildcard zu - erst das Projekt an sich zum Laufen bringen und dann optimieren.... UND nicht Vector, sonder ArrayList nehmen (wenn nur ein Thread läuft).

was zu problemen bei Vector/ArrayList machen kann sind einfügungen im Array bzw. Löschen eines Elements. Beim einfügen muss ja ab dem Einfügungsort alles eins nach rechts kopiert werden, beim löschen alles eins nach links.

Diese Probleme hast du aber auch wenn du mit einem normalen Array arbeiten willst und nicht null werte drin haben willst. Dann wäre eine LinkedList zu überlegen, die diese Problematik gar nicht hat. Dafür hat sie per se eine größeren Speicherbedarf wg den Referenzen die sich speichert...

 

[Corcovado]

@deathbyaclown

Das neu allozieren ist nicht das Problem des Vectors, sondern das hat man auch bei einem normalen Array !

Allokieren kostet nix in Java? Interessant!? Ein Array allokiere ich i.d.R. einmal und damit ist der Speicher festgelegt, es sei denn ich benoetige mehr Platz, dann muss ich neuen Speicher allokieren. Das macht evtl Vorteile von einem Array ggnueber einem Vector wieder etwas zunichte, das meinte ich hiermit ja auch:
Zitat ich:

tja Array == Array, aber das "drumrum" (Object, Allokation, Iteratoren, etc) hat doch auch konstruktoren (=Speicherallokation), dh fuer mich es kostet also (wenn die Denkweise so auch bei Java richtig sein sollte)?

afaik muesste ein Vector, allein schon weil er Objekte speichert einen Iterator besitzen - bei Arrays mit primitiven Typen reicht Index; einen Copy Constructor besitzen, bei Arrays prim Typen reicht eine Zuweisung, etc.
Was weis ich was java im Hintergrund noch rumbremst um Komfortabilitaet beim coden zu ermoeglichen, das macht fuer mich den Unterschied (u.a.).

Object hat erstmal nichts damit zu tun - Allokation hast du überall - Iterator wird beim erstellen gar nicht verwendet. Nur wenn du per iterator() einen anforderst....

Und wie funktioniert dann der Index in nem Vector, wenn es sich nicht um prim. Typen handelt, dafuer benoetigt der Vektor doch irgendwen, der ihm sagt, wie gross meine uebergebenen Objekte sind, damit es seinen Inhalt _sicher_ rauf und runter lesen kann, oder nicht?! Mir ist klar, dass wenn ich einen fertigen Vector haben will, ich mich da nicht rumschlagen will, was der im Hintergrund macht, solange er das macht, was ich von ihm erwarte.

wie gesagt - Vector ist eine "Wrapper" Klasse für Arrays. mehr nicht.

drumrum um ein array sozusagen... Das Array mit Armen, Beinen, Augen, Ohren und Nase wiegt also genausoviel wie ohne?!

ich stimme aber auch Wildcard zu - erst das Projekt an sich zum Laufen bringen und dann optimieren....

Ich hab bisher alles in einen Vektor von einem Vektor von String eingelesen, das war urlangsam (auf Pentium 2 und es gehoert eh nochmal generell ueberarbeitet).

Hae - laeuft doch...is nur langsam, u.a. vielelicht auch wegen dem Vector Dings.

was zu problemen bei Vector/ArrayList machen kann sind einfügungen im Array bzw. Löschen eines Elements. Beim einfügen muss ja ab dem Einfügungsort alles eins nach rechts kopiert werden, beim löschen alles eins nach links.

Kenne ArrayList nich, werds mir mal ansehn.

Diese Probleme hast du aber auch wenn du mit einem normalen Array arbeiten willst und nicht null werte drin haben willst.

naja, aber bei nem array kann ich nich einfach was einfuegen und dann alles nach hinten schieben, da muesste ich fuers letze element wieder ein neues allokieren - in sofern isses der selbe Kack, stimmt, wenn ich allerdings ne gewisse feste Groesse hab und erst ab ner hoeheren (ausnahmsweise), was dazuallokieren muss - isses denk ich schon ein Vorteil ggnueber nem Vector, der das von Hause aus immer macht.

Linked list - nix fuer ungut, aber da ich bleib dann doch eher noch bei Vector, denk ich...Vector is ja im Grunde auch nicht schlecht - es waere sicherlich nen Haufen Arbeit so was aehnliches (richtig) zu implementieren, was dagegen dann zB nur auf die eigene Funktionalitaet abgestimmt ist und DAHER etwa vielleicht Vektor ggnueber nen Vorteil hat. Werd mal schaun ob ich dazu was ergoogeln kann.

Werd mal einige der Neuanregungen hier ausprobieren, thx.

 

[Wildcard]

IMHO völlig unnötig sich über sowas gedanken zu machen. Vector/ArrayList sind einfache Arrays mit ein
paar Methoden zum Komfort. Wenn du über die vorhandene Größe element einfügst macht er eben ein neues Array.
Also nichts anderes als du auch machen würdest wenn du auf Arrays umsteigst. Was bringt das ganze dann?
Dein Performance-Problem liegt mit Sicherheit nicht am Vector (ausser vieleicht du nutzt ihn ineffektiv).

 

[Roar]

wie schon erwähnt - man kann dem Konstruktor die Größe des Arrays für den Vector angeben. Das neu allozieren ist nicht das Problem des Vectors, sondern das hat man auch bei einem normalen Array !

ich dachte da weniger an das allokieren, mehr an das kopieren aller elemente in den neu allokierten array. wenn man ne menge datenmengen hinzufügt muss der vector alle 10 (standart oda?) elemente ein neuen array allokieren und die alten elemente kopieren. wenn man 500 daten hinzufügt muss der vector das ganze 50 mal machen, bei einer allokierungsgröße von 500 nur einmal

 

[bygones]

Ich glaub du hast es noch nicht verstanden... Vectoren und ArrayListen sind intern ganz stink normale Arrays....

Allokieren kostet nix in Java? Interessant!? Ein Array allokiere ich i.d.R. einmal und damit ist der Speicher festgelegt, es sei denn ich benoetige mehr Platz, dann muss ich neuen Speicher allokieren. Das macht evtl Vorteile von einem Array ggnueber einem Vector wieder etwas zunichte, das meinte ich hiermit ja auch:

ich habe nie behauptet, dass das Allozieren nichts kostet - deine Argumentation ist aber falsch. Wenn du den Vector mit einer festen Größe initialisierst wirst du auch nicht neu allozieren. in beiden Fällen (Array / Vector) musst du wenn der Platz nicht ausreicht neuen Speicher allozieren. Beim Array musst du es halt von Hand machen, der Vector macht das automatisch. Also nochmal: Beide sind gleich der Vector bietet nur zusätzliche Methoden

afaik muesste ein Vector, allein schon weil er Objekte speichert einen Iterator besitzen - bei Arrays mit primitiven Typen reicht Index; einen Copy Constructor besitzen, bei Arrays prim Typen reicht eine Zuweisung, etc.

komplett falsch. Vector ist intern (wie gesagt) nichts anderes als Object[]. d.h. er arbeitet auch nur über index. Zugriff ist indexbasiert - wie in einem Array. Also hat er keinen Iterator. Wenn du die MEthode iterator() aufrufst wird ein Iterator Objekt erzeugt dass indexbasierend über den Array läuft.

Und wie funktioniert dann der Index in nem Vector, wenn es sich nicht um prim. Typen handelt, dafuer benoetigt der Vektor doch irgendwen, der ihm sagt, wie gross meine uebergebenen Objekte sind, damit es seinen Inhalt _sicher_ rauf und runter lesen kann, oder nicht?! Mir ist klar, dass wenn ich einen fertigen Vector haben will, ich mich da nicht rumschlagen will, was der im Hintergrund macht, solange er das macht, was ich von ihm erwarte.

basierend auf der Tatsache dass Vector intern Object[] ist - hast du das gleiche Problem bei einem Array.

naja, aber bei nem array kann ich nich einfach was einfuegen und dann alles nach hinten schieben, da muesste ich fuers letze element wieder ein neues allokieren - in sofern isses der selbe Kack, stimmt, wenn ich allerdings ne gewisse feste Groesse hab und erst ab ner hoeheren (ausnahmsweise), was dazuallokieren muss - isses denk ich schon ein Vorteil ggnueber nem Vector, der das von Hause aus immer macht.

nein - dem Vector kannst du die Größe auch angeben und ab welchem Füllungsgrad er neu allozieren soll. Daher ist der Vector eben vorzuziehen gg dem Array da er solche Problematiken für dich übernimmt.

Linked list - nix fuer ungut, aber da ich bleib dann doch eher noch bei Vector, denk ich...

warum?

Vector is ja im Grunde auch nicht schlecht - es waere sicherlich nen Haufen Arbeit so was aehnliches (richtig) zu implementieren, was dagegen dann zB nur auf die eigene Funktionalitaet abgestimmt ist und DAHER etwa vielleicht Vektor ggnueber nen Vorteil hat. Werd mal schaun ob ich dazu was ergoogeln kann.

wieso das Rad neu erfinden ? Swing ist auch nicht ausgereift aber deswegen was neues ?
nutze einfach nur die Funktionalitäten die du brauchst - solange du sie nicht nutzt brauchen sie keine Ressourcen. Ich finde ein indexbasierten Zugriff schon ziemlich ordentlich.

Nochmal: wenn du kein multithreading hast -> nehm ArrayList !!

Kleiner Tipp: Verwende in deinem Programm NUR die Interface zu den Klassen die du verwendest. D.h. außer beim erzeugen sollte NIE in deinem Programm Vector oder ArrayList stehen, sondern Collection oder List.

Warum? falls du doch mal siehst das eine ist besser als das andere - musst du nur bei der Erzeugung den Code ändern, dem Rest des Programms ist es ja dann egal welche Implementation aus welchen gründen genommen wird. Erleichtert einem das Optimieren und ist besseres Stil !!

 

[bygones]

ich dachte da weniger an das allokieren, mehr an das kopieren aller elemente in den neu allokierten array. wenn man ne menge datenmengen hinzufügt muss der vector alle 10 (standart oda?) elemente ein neuen array allokieren und die alten elemente kopieren. wenn man 500 daten hinzufügt muss der vector das ganze 50 mal machen, bei einer allokierungsgröße von 500 nur einmal

nicht richtig.

da wir immer so schön auf die API verweisen: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Vector.html#Vector(int,%20int)

und

Each vector tries to optimize storage management by maintaining a capacity and a capacityIncrement. The capacity is always at least as large as the vector size; it is usually larger because as components are added to the vector, the vector's storage increases in chunks the size of capacityIncrement. An application can increase the capacity of a vector before inserting a large number of components; this reduces the amount of incremental reallocation.

kurzfassung:
2 parameter. erster gibt an wie groß mein Vector sein soll, zweiter gibt mir den wert an, um den vergrößert werden soll. Default werte sind 10 und 0. Bei vergrößerungswert == 0 -> einfache verdoppelung. D.h. auch wenn du mit 5000,0 intialisierst, wird ein neuer Array immer mit der größe +5000 alloziert.

aber wie schon oben gesagt: wenn viele einfüge / lösch operationen vorhanden sind ist LinkedList besser ...

 

[Corcovado]

Gute Zusammenfassung - Danke.

Ich benutze Multithreading, allerdings brauche ich keinen synchonisierten Zugriff auf diese Datenstruktur (Vector, Arraylist, wtf auch immer). Der Vektor is hinter ner Facade - trotzdem denke ich isses schon etwas Aufwand, wenn man zB fuer ein reines Array den ganzen Komfort (effektiv) nachimplementiert, um zB nur die Methoden drin zu haben, die man benoetigt und den Rest, den zB ein Vektor eben bietet halt nicht.

Ich werds mal mit ner ArrayList versuchen, ich hab woanders noch das hier gefunden:

Something you should also know about Vectors: don't use them.
> Something you should also know about Vectors: don't use them.
Unless you are using a library like Swing. i.e. because you have to.
> ...so what's wrong with Vector
It's slow, because it's synchronized. It's also outdated. Use an ArrayList, it's much faster and provides the very same services.

"slow" und "outdated" ?!! :roll:

 

[bygones]

Ich werds mal mit ner ArrayList versuchen, ich hab woanders noch das hier gefunden:

Something you should also know about Vectors: don't use them.
> Something you should also know about Vectors: don't use them.
Unless you are using a library like Swing. i.e. because you have to.
> ...so what's wrong with Vector
It's slow, because it's synchronized. It's also outdated. Use an ArrayList, it's much faster and provides the very same services.

"slow" und "outdated" ?!! :roll:

outdated würde ich nicht sagen. Slow deswegen weil eben alle methoden synchronisiert sind... punkt

 

[Roar]

Bei vergrößerungswert == 0 -> einfache verdoppelung.

uff, sag das doch gleich dann hätte ich mir das sparen können
wusst ich ja nich dass der vector so intelligent ist :###

 

[Corcovado]

OK, hier sind nochmal n Paar Antworten die sich fuer mich logisch anhoeren und sich ausnahmsweise direkt auf das beziehen was ich wissen wollte, vielleicht bringts ja jemandem was der das hier mit der Suchfunktion irgendwann ausversehen rauskramt und ne aehnliche Grundsatzfrage hat. Ich will das nicht weiterausdiskutieren - sondern nur mal so das letzte Wort haben, hehe , da es nicht meine Antworten sind. Fakt ist, dass ich sicherlich praktisch gesehn erst rausfinden muss wo der Flaschenhals bei meinem Programm genau liegt. Andrerseits war/ist die Frage hier schon auch ein Grundsatzproblem. Mich wuerde es stark wundern, wenn in Java das Wasser bergauf fliessen wuerde.

> Vector/ArrayList/Arrays, I thought about improving that - sure...
All three have very fast indexed access of each element but there are differences. Arrays are fastest because there are no method calls. Then comes ArrayList. Vector is slowest because it's synchronized.
Performance is not determined by the data structure alone. It also depends on what the algoritm does. Arrays (whether static or dynamic (like ArrayList and Vector)) may not be the fastest option for your problem. The data structures and algoritms must be considered in conjunction.

Using arrays directly will offer the best performance. There is absolutely no need to use Vectors for anything except legacy code.
Using char[] in place of Strings is only worthwhile if you have a large number of small Strings.

PS.: Ob Vector "outdated" ist, oder "soooo schlau", kann ich nich beurteilen, da fehlt mir wieder mal das Wissen und die Zeit momentan. Mir riet nur bisher jeder, ausser manchen in diesem Forum, davon ab mit der Begruendung ich solle doch deren Suchfunktion benutzen, es gaebe zahlreiche Diskussionen darueber. Vectoren scheinen aus viellerlei Hinsicht nachteilig zu sein. kA mir aber jetz auch egal...