xHarbour vs Harbour
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Re: xHarbour vs Harbour
A just sent you the maps obtained with -s.
Please compare them and let me know.
EMG
Please compare them and let me know.
EMG
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Re: xHarbour vs Harbour
Enrico,
I have just compared them using UltraCompare (comes with UEStudio). if you compare both files there are very little differences.
What I have found so far is that these symbols are in xHarbour but they are not in Harbour:
I have just compared them using UltraCompare (comes with UEStudio). if you compare both files there are very little differences.
What I have found so far is that these symbols are in xHarbour but they are not in Harbour:
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Re: xHarbour vs Harbour
Funny thing is that xHarbour seems to have more linked symbols than Harbour, so how is it possible that Harbour EXE is larger ?
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Re: xHarbour vs Harbour
Ok, this is very interesting and may explain many things:
The code segments holds the code (not data, just code) and see their sizes:
in Harbour: 14CE0A
in xHarbour: 10CB5E
So that clear means that Harbour has more code into it than xHarbour.
Lets compare the amount of data that both use. data segment holds all the data (not code, just data):
in Harbour: 1723CC
in xHarbour: 14A0CC
Again Harbour uses more data than xHarbour.
Finally BSS segment stands for static variables:
in Harbour: 3C60
in xHarbour: AB9C
That means that xHarbour uses much more static variables than Harbour.
To me the above confirms my idea that Harbour is much more evolved than xHarbour and thus the difference in sizes. On a mid term, the software tends to grow as it grows in complexity and in maturity
The code segments holds the code (not data, just code) and see their sizes:
in Harbour: 14CE0A
in xHarbour: 10CB5E
So that clear means that Harbour has more code into it than xHarbour.
Lets compare the amount of data that both use. data segment holds all the data (not code, just data):
in Harbour: 1723CC
in xHarbour: 14A0CC
Again Harbour uses more data than xHarbour.
Finally BSS segment stands for static variables:
in Harbour: 3C60
in xHarbour: AB9C
That means that xHarbour uses much more static variables than Harbour.
To me the above confirms my idea that Harbour is much more evolved than xHarbour and thus the difference in sizes. On a mid term, the software tends to grow as it grows in complexity and in maturity
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Re: xHarbour vs Harbour
Antonio,
thank you. I just wrote to xHarbour developers mailing-list to know their thoughts about this subject.
EMG
thank you. I just wrote to xHarbour developers mailing-list to know their thoughts about this subject.
EMG
- Luis Krause
- Posts: 59
- Joined: Tue Oct 11, 2005 1:39 am
- Location: Vancouver, Canada
Re: xHarbour vs Harbour
Enrico:
Harbour links all the codepages modules, unlike
xHarbour (like Clipper did) in which you would need
to do a REQUEST to link the desired ones.
Like the above, I'm pretty sure Harbour links more
modules and likely even ones that are not available
in xHarbour, which would explain the difference
in size for the resulting .exe file.
Regards,
Harbour links all the codepages modules, unlike
xHarbour (like Clipper did) in which you would need
to do a REQUEST to link the desired ones.
Like the above, I'm pretty sure Harbour links more
modules and likely even ones that are not available
in xHarbour, which would explain the difference
in size for the resulting .exe file.
Regards,
"May the Source be with GNU"
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Re: xHarbour vs Harbour
Is there any way to exclude unused module from the Harbour EXE?
EMG
EMG
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Re: xHarbour vs Harbour
Enrico,
The simplest way that comes to my mind is implementing some dummy functions for modules that you don't need, so yours get linked in (with no code) and Harbour's ones get not linked in.
The simplest way that comes to my mind is implementing some dummy functions for modules that you don't need, so yours get linked in (with no code) and Harbour's ones get not linked in.
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Re: xHarbour vs Harbour
Antonio,
as I already wrote:
EMG
as I already wrote:
Why?No, this is not the cause of the difference. The same sample compiled for console (without FWH) shows: 889.856 bytes with xHarbour and 747.008 bytes with Harbour.
EMG
- Antonio Linares
- Site Admin
- Posts: 37481
- Joined: Thu Oct 06, 2005 5:47 pm
- Location: Spain
- Contact:
Re: xHarbour vs Harbour
Enrico,
Surely there are functions in FWH that once linked in require more code from Harbour than from xHarbour.
Why are you so much worried about the size ? its not so bad and it does not affect the app behavior at all
Surely there are functions in FWH that once linked in require more code from Harbour than from xHarbour.
Why are you so much worried about the size ? its not so bad and it does not affect the app behavior at all
- Enrico Maria Giordano
- Posts: 7355
- Joined: Thu Oct 06, 2005 8:17 pm
- Location: Roma - Italia
- Contact:
Re: xHarbour vs Harbour
Antonio,
EMG
Yes, it's not a real problem.Antonio Linares wrote:Enrico,
Surely there are functions in FWH that once linked in require more code from Harbour than from xHarbour.
Why are you so much worried about the size ? its not so bad and it does not affect the app behavior at all
EMG