rot13

Hallo,

beim Programmieren bin ich darauf gestoßen, dass der rot13 Konverter des Projekts Common.rot13(String) die eckigen Klammern nicht beachtet. Zumindest bei OpenCaching.de und Geocaching.com werden Texte in eckigen Klammern nicht konvertiert, damit aus
nicht
wird.

Daher scheint mir dieses Verhalten auch für den Cachewolf sinnvoll.
Bevor das jetzt jemand schreibt, ich hab das schon gemacht.

Dabei ist mir aufgefallen, dass zumindest wenn man klassisches Java betrachtet hier nahezu verschwenderisch mit dem Speicher umgegangen wird. Es wird für jeden Buchstaben ein neuer String erzeugt und der alte dem Garbagecollector überlassen. Hier wäre ein Stringbuffer oder aber händisch per char[] besser.
Oder optimiert hier EWE anders als Jave auf den kleinen Kisten? Meine großen Computer mit viel Ram und Prozessor dürfte das Egal sein, ich weiß aber nicht wie das auf Mobilen Geräten aussieht, gerade wenn die Hints länger sind.

Grüße Florian

ja, check das mal ein.
ich glaube kaum, dass ewe da was besser als die sun-java-vm optimiert.
Also, gerne Stringbuffer draus machen, obwohl das an dieser Stelle nun nicht besonders Zeitkritisch ist. Aber schaden kann es auch nicht.

Schöne Grüße,
Pfeffer.

Ja, mach ruhig einen Stringbuffer, wo es Sinn macht. Es wurde an vielen Stellen eher darauf geachtet, dass etwas funktioniert, und bei rot13 ist die Geschwindigkeit eher nebensächlich.

Moin Moin,

das Feature ist implementiert und ich hab das ganze jetzt mit nem char array gemacht. Außerdem mit rechnen statt mit stupidem Zuweisen. Dadurch ist der auch Quellcode deutlich kürzer ;-)
Normalerweise achte ich auch nicht so auf Optimierung (ogott, wofür haben unsere kisten ihre Gigahertz), aber da ich mich mit exportierem beschäftigt habe war mir das einfach aufgefallen und dann hab ich nebenbei euch über z.B. startgeschwindigkeit flennen hören ;-)

Da mein Passwort wohl noch nicht auf den SVN server kopiert ist werde ich das wohl erst morgen einchecken, mit glück morgens, mal gucken wie früh ich aufstehe ;-)

Grüße Florian