Defference between calling Functions defined in same unit and different units


    I made two projects. In first one, from the main unit I am calling 20 different functions defined in a single unit. In second project all these 20 functions made seperated in to 20 different units. The exe size of second one is found 1KB more than that of the first one.

   1) What is the exact reason for this exe size differnce?
   2) Is there any differnce in performace between the two exes (I couln't notice any. All the 20 functions were just a showmessage popup) ? Why?

  Pls give me some valuable comments.


Who is Participating?

Improve company productivity with a Business Account.Sign Up

Wim ten BrinkConnect With a Mentor Self-employed developerCommented:
Go to Project|Options, tabpage "Linker" and set "Map file" to "Detailed" for any of your projects. Then build that project and next to the resulting binary, you'll see a map file. If you look inside this map file, you can see which units are used, where they are located in the SINGLE codesegment and where theeir data is stored in the data segment. You will see lines like:

 Start         Length     Name                   Class
 0001:00000000 00055794H .text                   CODE
 0002:00000000 00001684H .data                   DATA
 0002:00001684 00002F79H .bss                    BSS

And this tells you where the code and data segments are. Next, you get lines like:

 0001:00000000 000050D0 C=CODE     S=.text    G=(none)   M=System   ACBP=A9
 0001:000050D0 00000174 C=CODE     S=.text    G=(none)   M=SysInit  ACBP=A9
 0001:00005244 00000B14 C=CODE     S=.text    G=(none)   M=Windows  ACBP=A9
 0001:00005D58 00000038 C=CODE     S=.text    G=(none)   M=Messages ACBP=A9
 0001:00005D90 000002C8 C=CODE     S=.text    G=(none)   M=SysConst ACBP=A9

The first four digits tell you in which segment this part of the code is located. Next you get the start position and length of the code that's put in your project. Then some information about what kind of data (code) is stored in that location and with the M=xxx you will know which unit this piece of binary belongs to.

A bit further you'll see a list of addresses of where your procedures and variables are located in the binary. And again, these addresses start with the segment ID of four digits.
Below this you'll see an overview of where your lines of code can be found in the binary. Then a list of resources included in your executable. And at the end you'll see the start address of your program.

LRHGuy is talking about near and far jumps but no... This is the old 16-bits way of thinking, where memory was still divided in multiple segments and calls were either far or near. But in 32-bits Windows you don't use many different code segments anyway. (You can, but there's no real use for it anymore.)

The growth could actually just be related to the fact that you just added another unit with a bit of code to your application. If every additional unit adds another 50 bytes to your application for it's initialization/finalization or whatever else, you will indeed notice a 1 KB (50x20) growth with 20 such units...
There's no difference in performance, though. One unit or 20 units, all function calls are just near calls...
Each unit that interfaces procedures necessitates making the routine "far", whereas when they are NOT interfaced, they are "near", in the same code segment. The compiler can optimize the call to near routines/procedures/functions. Interfaced procedures need some extra code, which I believe you found to be added a few more times becuase of all the extra units.

There probably is a speed difference, but it wouldn't be noticed until it was over several hundred or thousand calls to the procedure.

Just the nutshell version.
binu_emmesAuthor Commented:


    Thanks Workshop_Alex and LRHGuy for your comments.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.