Hashtable v/s String Manipulation

[deneb shah]

Me again....
I have a String sent it like
[sometag]IPAddress[/sometag][someothertag]SomeID[/someothertag]FunctionName*param1,param2,...
The present scenario :
take the string using indexOf, substring,.. all the string manipulations put it in String varaibles ... then put all the params in the vector and pass it to a function..
what i suggets is that using indexof & substring, put everything in a hashtable and pass that hashtable..
by doing this u avoid
1) String Objects...
2) the need of creating a vector
would my suggestion be a discarded ???
i know that if there arent much param elements and if the String is small then there will be an overhead...
but still i feel that my suggestion is the right way of doing it.. a generic approach... but is this going to affect the performance....???
what if the data is something like this
< A>...< /A>[ b]...[ /b]< C>...< /C>
i do not want to use xml parsers as they make it pretty heavy...
Thnx
------------------
denice the menace
[This message has been edited by Jim Yingst (edited March 30, 2000).]

[Jim Yingst]

I put some spaces inside your HTML tags so the browser would display them as text, rather than trying to interpret them, which tends to make them vanish.
Offhand, I don't think it will make too much difference either way. A Hashtable or HashMap will have a pair of Strings - a key and a value - for each entry. E.g.
key -> value
"A" -> string between A tags
"B" -> string between B tags
"C" -> string between C tags
A Vector should just have a single String object for each entry. Which makes me wonder how they tell which String goes with which property. Are there a fixed number of different properties, and is each property mapped to a different index in the Vector? In that case an array might be more appropriate. And as for the indexOf and substring, you'll still need those to find and create the strngs that get used as keys and values in the hashtable.
I do like the idea of a hashtable here for ease of use. It seems like the natural data structure to associate an arbitrary number of value pairs. And if you want to look up the value of say, attribute "C", it's simple: hashtable.get("C"). I'm not sure how you do it in the Vector; it depends just how the values are stored there. But I doubt it's as simple.
Best guess - performance and memory usage will be pretty much the same with a hashtable as with a vector, except when you do loookup. There the hashtable will most likely be faster. And my guess is that it will also give you clearer-looking code, the importance of which should never be underestimated.

[deneb shah]

Dude Jim...
rightly called the Mr. Sheriff..
u never fail to impress me.. man salutes to u...
i feel honored if u reply to my messages..
regarding the problem
what i just wanted to clear that
[tag]..[/tag]FuncName*param1,param2,...
all the params are taken in a vector and passed to the function FuncName..
Individual params are not taken as vectors...
what do u feel if this si the case
the look up may just be once.. or twice not much
------------------
denice the menace

[Jim Yingst]

Awww, now I'm blushing...
(Though I'm about to leave for the weekend, so don't take it personally if I don't respond further for a few days.)
I had overlooked the function parameter list within the other tags. That part of the data actually does seem better suited to a Vector, as with a hashtable you need some sort of unique key for each entry. You can make up some naming convention - e.g.
"FunctionName1" -> "param1"
"FunctionName2" -> "param2"
etc.
But you're spending addtional time and memory creating the strings for the keys. With a Vector, you can just use the index number:
Vector FunctionNameParams = new Vector();
FunctionNameParams.add("param1"); // index 0
FunctionNameParams.add("param2"); // index 1
etc.
So I gather all the other attributes are not part of the Vector, but just get stored in separate String variables? This works great as long as you know in advance what all the attribute names are, so you can make a variable for each. Storing and looking up the individual String variables via their own separate identifiers will be faster than storing and accessing through a hashtable I think. With a hashtable however, you could write something that just puts all attribute names and values in the hashtable, whether you've heard of them or not, and pass that hashtable off to other components. Your code need only look up the attributes it knows/cares about - others will still be there in the hashtable, and if you later discover a need for them, you can add the code to look them up at whatever point in the code seems most convenient, as long as it has access to the hashtable. And if you're dealing with something like XML that can define new attributes on the fly, this sort of flexibility would be necessary. But it will run slower than the non-hashtable version I think, so for a fixed list of attributes it sounds like the existing system is the way to go. Again, assuming I've understood the system.

[This message has been edited by Jim Yingst (edited March 31, 2000).]