NewBond() (was: hydrogens and avogadro)

Donald Ephraim Curtis wrote:

Yes, we should really fix NewBond. The reason for the OBBondIncrement
is so that memory allocation is done in chunks, not at every call. I
think Chris put this in. I’ll patch up OB or you can.

I’m not responsible for ALL the less-than-perfect coding in OB!

I think this oversizing of OBBond and OBAtom arrays is of long standing.
Using the reserve() function rather than resize() might be a better way.

Chris

On 2/24/07, Chris Morley c.morley@gaseq.co.uk wrote:

Donald Ephraim Curtis wrote:

Yes, we should really fix NewBond. The reason for the OBBondIncrement
is so that memory allocation is done in chunks, not at every call. I
think Chris put this in. I’ll patch up OB or you can.

I’m not responsible for ALL the less-than-perfect coding in OB!

I think this oversizing of OBBond and OBAtom arrays is of long standing.
Using the reserve() function rather than resize() might be a better way.

I tried this, but it didn’t seem to work. So I used the same approach as the
NewAtom method. This means checking if the vector is large enough, if not,
resize to current size + OBBondIncrement, add the new bond using
_vond[_nbonds] = … instead of the _vbond.push_back(). This is allready in
svn by the way. I think this is a reasonable patch, but feel free to play
around with reserve(), at first I also expected this would solve the
problem.

Tim

Haha! Ah Chris I wasn’t pickin’ on you. And i never said it was bad or
anything. For some reason i just have you in my head as the
optimization guy. So whenever it looks like something was put in for
optimization sake i’m already kinda looking to you for input…

(Sat, Feb 24, 2007 at 09:50:10AM +0000) Chris Morley c.morley@gaseq.co.uk:

Donald Ephraim Curtis wrote:

Yes, we should really fix NewBond. The reason for the OBBondIncrement
is so that memory allocation is done in chunks, not at every call. I
think Chris put this in. I’ll patch up OB or you can.

I’m not responsible for ALL the less-than-perfect coding in OB!

I think this oversizing of OBBond and OBAtom arrays is of long standing.
Using the reserve() function rather than resize() might be a better way.

Chris


Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On Feb 24, 2007, at 4:50 AM, Chris Morley wrote:

Donald Ephraim Curtis wrote:

Yes, we should really fix NewBond. The reason for the
OBBondIncrement
is so that memory allocation is done in chunks, not at every call. I
think Chris put this in. I’ll patch up OB or you can.

I think this oversizing of OBBond and OBAtom arrays is of long
standing.
Using the reserve() function rather than resize() might be a better
way.

Actually, we probably don’t even want OBBondIncrement anymore,
although reserve() might be useful.

Most STL implementations take care of behind-the-scenes resizing of a
vector. So if you know the size from the beginning, use reserve().
Otherwise, it’s probably better to let the STL experts handle it.
They’re usually pretty good about getting the performance as close to
optimal as possible.

(BTW, this code dates to Open Eye.)

Cheers,
-Geoff