A just sent you the maps obtained with -s.
Please compare them and let me know.
EMG
FiveTech Support Forums
FiveWin / Harbour / xBase community
Board index FiveWin for Harbour/xHarbour xHarbour vs Harbour
Page: 1 2 (28 posts)
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:
Funny thing is that xHarbour seems to have more linked symbols than Harbour, so how is it possible that Harbour EXE is larger ? 
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
Antonio,
thank you. I just wrote to xHarbour developers mailing-list to know their thoughts about this subject.
EMG
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,
"May the Source be with GNU"
Thank you for the infos, Luis.
EMG
Is there any way to exclude unused module from the Harbour EXE?
EMG
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.
Antonio,
as I already wrote:
Why?
EMG
as I already wrote:
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.
Why?
EMG
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
Antonio,
Yes, it's not a real problem.
EMG
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
Yes, it's not a real problem.
EMG
Page: 1 2 (28 posts)