 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Gabriel Corneanu gabrielc
Guest
|
 Posted: Thu Oct 06, 2005 9:15 am Post subject: Object Creation (was objpool) again |
 |
|
Hi all,
As Eric said, when the memory manager if good enough there might not be a further speed increase using pooling. One or to extra calls (to the MM) might be balanced by the extra FreeInstance redirection.
In my tests this approach is pretty fast and somehow easier to follow than the other version, so I focused mainly on this variant.
Eric already added different handling for different types for classes (see below).
My changes (from Eric's version):
- renamed unit to FastObj and the main class to TObjectAccelerator
there is no explicit pooling anymore in this version
- created allocator for dynamic code
- created option to disable global optimization
use OptimizeClass instead to optimize individual classes
- switch for version independent (no direct calls to FastMM)
- fixed memory leaks
- removed class name from offset asm statements, to avoid trouble when
renaming the class (already did)
Some people with better ASM knowledge could help optimizing the loops.
As I can see now, it should work as long as these conditions are met:
For interfaced objects, a full copy is made from the template. This means it will work if all values set in AfterConstruction are static (nothing like Random()  ); that's the way TInterfacedObject works.
For non interfaced objects, the content is zeroed. It will NOT work if any value is set in AfterConstruction.
I have never seen classes which would fail on these conditions.
Some questions for Eric (and anyone else interested):
You used several Int64 conversions in pointer operations. I think you did this to prepare for 64 bit version.
In my opinion this is not necessary (and currently is introducing an extra overhead). According to Borland help, integer and cardinal are generic types which are mapped to processor type. That means they will be 64 bit on 64 bit compiler.
Am I wrong here?
In the same way I tried to make some other constants independent of compiler version (32/64 bit). Please tell me anything which doesn't look right.
It's posted back to attachments, including a dummy test.
Gabriel
|
|
| Back to top |
|
 |
Eric Grange
Guest
|
| Posted: Thu Oct 06, 2005 10:05 am Post subject: Re: Object Creation (was objpool) again |
|
|
You're version hasn't appeared in the attachments yet here...
so I'm not commenting anything code-specific :)
| Quote: | [...] This means it will work if all values set in
AfterConstruction [...]
|
Haven't seen your code, but AfterConstruction is a magic function added
by the compiler after Create (constructor) has occured. As long as we
stick to NewInstance level, whatever happens in AfterConstruction
shouldn't affect us. The limitation is thus only not to have object
initializations in NewInstance, but only in constructors, which
shouldn't mean any trouble.
| Quote: | You used several Int64 conversions in pointer operations.
I think you did this to prepare for 64 bit version.
|
No, this was to prepare for 4 GB mode usage (which FastMM allows)
without investing too much "thinking time".
They are in non-critical, executed-once-per-class code sections so
performance isn't really an issue here.
Eliminating the need for a template might be desirable, if only to avoid
waste in the rare cases where object field data is truly large (like a
huge static array in a fixed-size matrix or vector class f.i.).
| Quote: | It's posted back to attachments, including a dummy test.
|
Since we are currently two working on fundation/feasability phase, and
basicly working on the same unit, I would like to go CVS... there is
this old fastcode project I created way back on SourceForge and that is
just begging to be used
All that would be needed would be your SF sourceforge account login and
getting TortoiseCVS (or another CVS client) and I could set things up
there if you agree.
I think we should also split the VMT/jump/other patching stuff to
another unit to keep FastObj focused on objects (plus this could become
the basis of a code-patching library).
On the rest of the optimization, things look a bit more complex from
that point forward, as many of the functions involved are System-private
or compiler magic, ie. a bit harder locate and patch, there is potential
from refcounting to cleanup... but getting to it isn't straightforward.
Eric
|
|
| Back to top |
|
|
Gabriel gabrielcorneanuAT
Guest
|
| Posted: Thu Oct 06, 2005 10:55 am Post subject: Re: Object Creation (was objpool) again |
|
|
Eric Grange <egrangeNO (AT) SPAMglscene (DOT) org> wrote:
| Quote: | You're version hasn't appeared in the attachments yet here...
so I'm not commenting anything code-specific :)
|
Sorry, I can't attach right now. I sent it to you by email.
Gabriel
|
|
| Back to top |
|
|
Eric Grange
Guest
|
| Posted: Thu Oct 06, 2005 11:30 am Post subject: Re: Object Creation (was objpool) again |
|
|
| Quote: | Sorry, I can't attach right now. I sent it to you by email.
|
Posted it in the attachments.
Eric
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
