Hi,
I am looking for a clean way, how to get rid of the heap marking in gpc-20030830. It seems to me that the simplest way how to do it now, is to comment the
Mark (FirstMark)
statement in system.pas:808 (initialization code), but I think that there should be a better way, particularly after reading this GPC posting: http://www.gnu-pascal.de/crystal/gpc/en/mail8202.html . It says:
PrepareDisposePointer shouldn't do much unless `Mark' is used (anywhere in the program) which, e.g., the `HeapMon' unit does. If you use either of them, this probably explains it. `Mark' is not optimized for speed (I consider it mostly an outdated and/or debugging thing).
The speed-up factor is pretty significant - 8-12 times faster without marking - since I have milions or tens of milions (de)allocations.
Thanks for any advice, Josef Urban
Josef Urban wrote:
I am looking for a clean way, how to get rid of the heap marking in gpc-20030830.
A clean way is, of course, not having to use the `System' unit at all. It's meant for the last bits of BP compatibility which can't be implemented in a cleaner way.
Which features of `System' do you (think you) need? If you use `System' only because you're used to it from BP, just get rid of it.
It seems to me that the simplest way how to do it now, is to comment the
Mark (FirstMark)
statement in system.pas:808 (initialization code), but I think that there should be a better way, particularly after reading this GPC posting: http://www.gnu-pascal.de/crystal/gpc/en/mail8202.html . It says:
PrepareDisposePointer shouldn't do much unless `Mark' is used (anywhere in the program) which, e.g., the `HeapMon' unit does. If you use either of them, this probably explains it. `Mark' is not optimized for speed (I consider it mostly an outdated and/or debugging thing).
The speed-up factor is pretty significant - 8-12 times faster without marking - since I have milions or tens of milions (de)allocations.
If really necessary, we could add another conditional (like the other three), at the cost of breaking `AllocMemSize' and `AllocMemCount'.
Frank
On Tue, 4 May 2004, Frank Heckenbach wrote:
Josef Urban wrote:
I am looking for a clean way, how to get rid of the heap marking in gpc-20030830.
A clean way is, of course, not having to use the `System' unit at all. It's meant for the last bits of BP compatibility which can't be implemented in a cleaner way.
Which features of `System' do you (think you) need?
Probably quite a lot of the system.pas stuff: BP types like Byte and Word, constants like MaxInt, Settextbuf and ExitProc, maybe more.
If you use `System' only because you're used to it from BP, just get rid of it.
There is quite a lot of these BP things in our code, so removing it is some effort. Moreover, we now compile with FPC, Kylix and Delphi, and things like Settexbuf are useful there. We could do more ifdef-ing, or have our own compatibilty layer, but using system.pas seems to be the cheapest way. Maybe I will just copy the needed things to some 'gpcsystem.pas' and use it instead of system for gpc.
Thanks, Josef
Josef Urban wrote:
On Tue, 4 May 2004, Frank Heckenbach wrote:
Josef Urban wrote:
I am looking for a clean way, how to get rid of the heap marking in gpc-20030830.
A clean way is, of course, not having to use the `System' unit at all. It's meant for the last bits of BP compatibility which can't be implemented in a cleaner way.
Which features of `System' do you (think you) need?
Probably quite a lot of the system.pas stuff: BP types like Byte and Word, constants like MaxInt, Settextbuf and ExitProc, maybe more.
Only two of them are in `System' actually.
If you use `System' only because you're used to it from BP, just get rid of it.
There is quite a lot of these BP things in our code, so removing it is some effort. Moreover, we now compile with FPC, Kylix and Delphi, and things like Settexbuf are useful there. We could do more ifdef-ing, or have our own compatibilty layer, but using system.pas seems to be the cheapest way. Maybe I will just copy the needed things to some 'gpcsystem.pas' and use it instead of system for gpc.
I don't suggest so. People often underestimate the troubles of code duplication. The initial copying is easy, of course, but keeping it up to date will cause unncessary effort in the long run.
As I said, I think we could add another conditional. Perhaps something like `__BP_NO_ALLOCMEM__' (any other suggestions)?
Frank
On Tue, 4 May 2004, Frank Heckenbach wrote:
Josef Urban wrote:
Maybe I will just copy the needed things to some 'gpcsystem.pas' and use it instead of system for gpc.
I don't suggest so. People often underestimate the troubles of code duplication. The initial copying is easy, of course, but keeping it up to date will cause unncessary effort in the long run.
Mostly yes, though sometimes you don't want to keep up with all the fancy stuff provided by others, and are happy with you own minimal implementation :-).
As I said, I think we could add another conditional. Perhaps something like `__BP_NO_ALLOCMEM__' (any other suggestions)?
I would obviously welcome it. As for other suggestions, command line option also comes to mind ( --no-bp-alloc or similar), but at the first glance this seems a bit harder to do for System.pas ( I am no gpc expert).
Josef
Josef Urban wrote:
On Tue, 4 May 2004, Frank Heckenbach wrote:
Josef Urban wrote:
Maybe I will just copy the needed things to some 'gpcsystem.pas' and use it instead of system for gpc.
I don't suggest so. People often underestimate the troubles of code duplication. The initial copying is easy, of course, but keeping it up to date will cause unncessary effort in the long run.
Mostly yes, though sometimes you don't want to keep up with all the fancy stuff provided by others, and are happy with you own minimal implementation :-).
Unless/until it breaks sometime. Units shipped with GPC will always be adjusted to any necessary changes in the compiler or other units ...
As I said, I think we could add another conditional. Perhaps something like `__BP_NO_ALLOCMEM__' (any other suggestions)?
I would obviously welcome it.
Patch attached.
As for other suggestions, command line option also comes to mind ( --no-bp-alloc or similar), but at the first glance this seems a bit harder to do for System.pas ( I am no gpc expert).
Yes, and besides any conditional can be given as a command line option anyway (-D__BP_NO_ALLOCMEM__).
Frank
-
Frank Heckenbach -
Josef Urban