Egon wrote:
>> The atom values themselves don't get reused. But the array which holds
>> them can be reused.
>
> Ok, but what I do not have clear yet, is what happens when doing this:
> - say you have an array of length 10 all with Atom set to some value
> - then you need to enlarge... I guess new Atom[10+enlargement] will
> erase the previous values, correct?
> - so you always need to copy them into the new array?
[snip]
>> ... it should say something like
>> if (atomCount == 0)
>> allocate-the-atoms(tokenCount);
>> else if (tokenCount != atomCount)
>> throw-an-exception
>
> There was one minor thing complicating this setup... you don't know
> the number of tokens untill you parsed the first attribute... but I guess
> this should work...
These two are closely related.
Let's try thinking of it a different way for a moment.
Let us assume that we allocate the atomArray to be of effectively infinite
size ... 1 million.
The atomCount variable contains the number of atom objects that are
currently stored in the array. Its value will either be zero or non-zero.
If we see that the current value is zero then we will allocate the atoms:
if (atomCount == 0) {
atomCount = tokenCount;
for (int i = atomCount; --i >= 0; )
atomArray[i] = new Atom();
}
Otherwise, if the atomCount is non-zero, then the tokenCount for this
attribute had better be exactly the same as the atomCount. In which case,
we don't have to do anything.
else if (atomCount != tokenCount)
throw SomeException;
Later on, when we reach the </atomArray> tag, we will move these
atomObjects to the model and reset the atomCount to 0.
Are you with me?
Now, we don't want to allocate the atomArray to be some big number. So we
may need to extend the size from time-to-time.
But the only time that we make it bigger is when atomCount == 0 ... when
it is empty.
if (atomCount == 0) {
if (tokenCount > atomArray.length)
atomArray = new Atom[tokenCount];
for (int i = tokenCount; --i >= 0; )
atomArray[i] = new Atom();
atomCount = tokenCount;
}
Let me know if this still is not clear.
>> One warning flag is a 'new' operation which happens in a loop. The
>> expense
>> is in the reclamation (garbage collecting) more than the allocation.
>
> Ack. You mentioned this before... is that the only thing I should be aware
> of when writing efficient code?
It is *one* of the things.
The fact that Java automatically reclaims unused objects (garbage
collects) is a *great* thing.
However, it can be a major source of performance problems. And a source of
'hiccups' in your system ... when your program pauses unexpectedly to
reclaim garbage.
Programmers who have never worked in a language with explicit heap memory
allocation (like alloc/malloc in C) often have a hard time visualizing and
appreicating this.
Developers who want to write efficient/systems-quality code still need be
be *aware* of when objects are being created ... and avoid doing so
unnecessarily.
>> The current code is resizing the atomArray if (tokenCount > atomCount)
>>
>> I think this is a mistake ... it should say something like
>> if (atomCount == 0)
>> allocate-the-atoms(tokenCount);
>> else if (tokenCount != atomCount)
>> throw-an-exception
>
> There was one minor thing complicating this setup... you don't know
> the number of tokens untill you parsed the first attribute... but I guess
> this should work...
At the time that you parse/tokenize the first attribute the value of
atomCount will be 0.
Since atomCount == 0, there are effectivly no atom objects in the
atomArray. (There will be pointers to the *old* atom objects filling up
the array, but we are not using them anymore and they are not important)
Therefore, you can just allocate a new atomArray of the size we need
(which will be happen to be filled up with nulls.)
Miguel
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Jmol-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
