NO

Author Topic: Why compile Pelles C so slow?  (Read 25864 times)

linnar

  • Guest
Why compile Pelles C so slow?
« on: August 31, 2011, 12:49:42 AM »
I do programming in LccWin32.

 I'm trying to program an accounting software. The source code is 1292 kb.
 When I compile my source code in the LCC, it takes 2-4 seconds for the LCC to build one. Exe file  ;) .

 But LccWin32 editor Wedit, has  bugs, I want to switch to Pelle's C. But when I compile in Pelle's C, it takes more than 120 seconds  :o  ???

 Pelle's C based on the LCC so then I wonder why it takes so long to compile?

CommonTater

  • Guest
Re: Why compile Pelles C so slow?
« Reply #1 on: August 31, 2011, 02:56:14 AM »
Turn off all optimizations and try it again... Optimizing compilers are often slower because they do a lot more work for you.

JohnF

  • Guest
Re: Why compile Pelles C so slow?
« Reply #2 on: August 31, 2011, 09:17:41 AM »
Try using #define WIN32_LEAN_AND_MEAN before including windows.h where possible and where its not try some of these.

#define NOCRYPT
#define NOSERVICE
#define NOMCX
#define NOIME

Look up these defines so that you understand them.

Also, the reason LCC-Win32 is so fast is that the author uses his own headers - this cuts down greatly the compile time.

EDIT: PellesC headers are basically the same as Microsoft ones.

Also make sure you are not including headers where they are not necessary. I have often seen C files including many headers that are not needed for that particular C unit. Often this happens during development, just pop in a header for a particular purpose and then one forgets to take it out if its not needed later on.

John
« Last Edit: August 31, 2011, 09:31:47 AM by JohnF »

linnar

  • Guest
Re: Why compile Pelles C so slow?
« Reply #3 on: August 31, 2011, 01:07:13 PM »
Thanks for your suggestions!

I use
 # define WIN32_LEAN_AND_MEAN
but not
 # define NOCRYPT
 # define NOSERVICE
 # define NOMCX
 # define NOIME
Must try it, thanks for the tip!

I use a few extra lib for different reasons.
I have my own h-lib that contains 830 features. I always include everyone.

1. Should I just include what I need from my lib?

2. Should I just include the Pelle's lib that I need?

3. If I add LCC-Win32 libs in Pelle's system, I can instead use Pelle compile any of the LCC-Win32 lib?
My idea is to switch between them as needed.

4. Can I replace all the binaries in PellesC for LCC-Win32?
I must, of course rename the binaries to the same as PellesC have.

I have worked a few days in PellesC with my big program. I have to change very much code for it to work. It still does not work, has much to do. This is to avoid having to rebuild everything that I add this program to use PellesC with LCC-Win32's lib.

Here's my program for download (in Swedish, unfortunately):
http://www.firmabok.com

Sorry for my bad English!
« Last Edit: August 31, 2011, 01:09:32 PM by linnar »

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 2107
Re: Why compile Pelles C so slow?
« Reply #4 on: August 31, 2011, 02:40:14 PM »
Quote
4. Can I replace all the binaries in PellesC for LCC-Win32?
I must, of course rename the binaries to the same as PellesC have.
Not an good idea. Create new or copy PellesC project and change it for LCCWin32.
There is Add-In for it http://forum.pellesc.de/index.php?topic=3250.msg13922#msg13922

For example:
Code: [Select]
POC_PROJECT_VERSION = 6.50#
POC_PROJECT_TYPE = 0#
POC_PROJECT_OUTPUTDIR = output#
POC_PROJECT_RESULTDIR = .#
POC_PROJECT_ARGUMENTS = #
POC_PROJECT_WORKPATH = #
POC_PROJECT_EXECUTOR = #
CC = c:\code\lcc-win32\bin\lcc.exe#
RC = c:\code\lcc-win32\bin\lrc.exe#
LINK = c:\code\lcc-win32\bin\lcclnk.exe#
CCFLAGS = #
RCFLAGS = -r#
LINKFLAGS = -subsystem:windows kernel32.lib user32.lib gdi32.lib comctl32.lib comdlg32.lib advapi32.lib#
INCLUDE = ..\..\..\lcc-win32\include#
LIB = ..\..\..\lcc-win32\lib#

#
# Build WSDIFrame.exe.
#
WSDIFrame.exe: \
output\WSDIFrame.obj
$(LINK) $(LINKFLAGS) -out:"$@" $**

#
# Build WSDIFrame.obj.
#
output\WSDIFrame.obj: \
WSDIFrame.c
$(CC) $(CCFLAGS) "$!" -Fo"$@"

.EXCLUDEDFILES:

.SILENT:
May the source be with you

CommonTater

  • Guest
Re: Why compile Pelles C so slow?
« Reply #5 on: August 31, 2011, 04:13:20 PM »
I use a few extra lib for different reasons.
I have my own h-lib that contains 830 features. I always include everyone.

How is this h-lib written...  Pelles C compiles at the object level, each object being one page of source code.  If your 830 features are in less than 830 source files, POLINK is going to link huge blobs (or *all*) of that library into your final program, producing bloatware with a lot of dead code in it.  And, searching through an 830+ line header to find the only function you are using from that library, for every source page in a complex project does indeed take some time...

Quote
1. Should I just include what I need from my lib?

2. Should I just include the Pelle's lib that I need?

On a page by page basis you should never include anything that is not *absolutely necessary* for that page of source code.  Searching header files takes time... searching 30 headers that have nothing you need is a complete waste of time.

Also, since large projects tend to get rather tangled up as things include other things and they include other things, you should be sure to use "include guards" everywhere...  In case you're not sure what I mean you can use...
Code: [Select]
#ifndef HEADERNAME_H
#define HEADERNAME_H

// place header statements here

#end if // HEADERNAME_H
... to prevent the compiler from reading header files more than once.  Pelles C also includes the #pragma once for this purpose but that may spoil interchangeability between compilers.


Quote
3. If I add LCC-Win32 libs in Pelle's system, I can instead use Pelle compile any of the LCC-Win32 lib?
My idea is to switch between them as needed.

Bad idea... libs have to contain the functions promised in headers... you will most likely end up with no end of linker errors and an even bigger mess than you have now.

Frankly... my advice to you would be "pick one, and stick with it" ...

Quote
4. Can I replace all the binaries in PellesC for LCC-Win32?
I must, of course rename the binaries to the same as PellesC have.


First of all, I would never suggest trying anything even remotely like that... you're looking for "command line hell" as many of the compiler and linker switches may have the same names but do something entirely different. 

IF you want to go multi-compiler in POIDE ... use Timo's addin ... at the link he provided.


Quote
I have worked a few days in PellesC with my big program. I have to change very much code for it to work. It still does not work, has much to do. This is to avoid having to rebuild everything that I add this program to use PellesC with LCC-Win32's lib.

In my experience (which is admittedly limited to hobby projects) trying to get smart with compilers usually has the exact opposite of the desired effect... Using LCC's headers and libs with Pelles C may seem like a great solution, in theory, but in practice you're very likely to break more than you fix ...

My suggestion would be to use a clean Pelles C install, no trickery... work on a copy of your source code --definately not the ONLY copy-- and clean up your includes then go through and fix whatever errors get reported from the compiler.  Rebuild whatever private libraries you have with Pelles C (See notes above) and go for it...


« Last Edit: August 31, 2011, 04:33:51 PM by CommonTater »

linnar

  • Guest
Re: Why compile Pelles C so slow?
« Reply #6 on: August 31, 2011, 04:38:14 PM »
Thank you all!

 I have read everything but do not have time to comment on the now.

 This sounds most correct:

Quote
My suggestion Would be to use a clean Pelle's C install, no trickery ... Work on a copy of your source code - definitely not the ONLY copy - and clean up your includes hadeeth go through and fix whatever errors get reported from the compiler. Rebuild whatever private libraries You Have with Pelle's C (See Notes above) and go for it ...

I am also curious about the proposal with the add-in as "timovjl" showed above.

 I returned amount coats when I tried all the suggestions!

linnar

  • Guest
Re: Why compile Pelles C so slow?
« Reply #7 on: September 01, 2011, 07:33:33 AM »
Hello all!
This forum has a lovely setting in!


I have now tested
# Define NOCRYPT
# Define NOSERVICE
# Define NOMCX
# Define NOIME
Slightly shorter compilation time perhaps but not that it shows.


I included only the includes from my lib is used. Now compile it faster but still way too long. I can not sit and wait 1-2 minutes when the compilation is in progress.
I may begin to exclude PellesC lib that are not used but it is a big job.

But I'm beginning to think I can never come down in 2-4 seconds compilation time by 1.2 mb source. It is sad because I really enjoy PellesC editor.

- How long does it take to compile the rest of you? Source size?
- I get lots of warnings, may increase the compilation time?

I will also test timovjl proposal of using LccWin32 in PelelsC.
I have downloaded. ZP file and tried a little but I do not understand how this works. There is no button for Lccwin32. The point is that I will use one button to another name?
I was not looking so long for it to look more when I get time.

Can anyone describe exactly how this is installed in PellesC?

Hope you understand what I write

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 2107
Re: Why compile Pelles C so slow?
« Reply #8 on: September 01, 2011, 08:43:38 AM »
In dialog 'Select comp..' select Options and give Title like LccWin32 and press New to add new entry.
When you reopen Select compiler dialog the new button should be there.
There is now button to delete option too and some other fixes.
« Last Edit: September 01, 2011, 11:11:19 AM by timovjl »
May the source be with you

JohnF

  • Guest
Re: Why compile Pelles C so slow?
« Reply #9 on: September 01, 2011, 08:45:18 AM »
You only need to rebuild the whole project rarely.

From the help file:

To build the active project, select Build name on the Project menu...

This will build all target files where the source file, or one of it's dependencies, have changed since the last build.


You will find that using Build is much faster than a rebuilding the whole project.

John

linnar

  • Guest
Re: Why compile Pelles C so slow?
« Reply #10 on: September 01, 2011, 11:24:00 AM »
In dialog 'Select comp..' select Options and give Title like LccWin32 and press New to add new entry.
When you reopen Select compiler dialog the new button should be there.
There is now button to delete option too and some other fixes.
OK!
I tested a little now and I got a new button. Should test more when I get home.
THANKS!

linnar

  • Guest
Re: Why compile Pelles C so slow?
« Reply #11 on: September 01, 2011, 11:26:17 AM »
You only need to rebuild the whole project rarely.

From the help file:

To build the active project, select Build name on the Project menu...

This will build all target files where the source file, or one of it's dependencies, have changed since the last build.


You will find that using Build is much faster than a rebuilding the whole project.

John
Well, why did not I think of it! Sometimes I think too deeply and miss the simple.
Must test it when I get home!
Thank you for teaching me to use my head  ;)  !

linnar

  • Guest
Re: Why compile Pelles C so slow?
« Reply #12 on: September 01, 2011, 11:50:51 AM »
I have seen similar problems with other developing systems. There should be a document called "New to Pelle-C. Read this first" or something similar.
In that document, there should be advice on how it is to switch from other systems and how their work is converted to Pelle-C. Undocumented tips could also be found here as well timovjl clever little program and how to use and much more. For example, selected savvy tips in the forum.

That would make it easier for developers to switch to Pelle-C as we developers often are super conservative.


I based the idea on how I experienced my first contact with the Pelle-C and other development packages changes I made​​. It has always been the same problem with changing the small details here and there. It will be hours behind the forum search function and endless testing before it works without problems.

I began to develop in basic on the Commodore VIC20
then moved according to the list:
Basic - Commodore 64
Amiga basic - Amiga 500
HisoftBasic - Amiga 500
SAS C - Amiga 500
Symatec C / C + + - WinPC
LccWin32 - WinPC

Has also worked in AMOS, Blitz Basic and more on the Amiga
When Symantec closed down its C / C + + I was looking for something else that is updated. I tried lots of different C-tool (do not use C + +) until I got stuck for LccWin-32. Now it seems that it does not evolve more and therefore I must move on to something else. I have been looking at Pelle-C for a few years ago and now wants to give the tool a try.

At each change and test of the other tools I have had problems with my source codes that could not be used as they are. I had to modify a lot. When I tested LccWin-32 worked my codes without modification. That's why I chose that package.

I really have no documents about how to convert. Many hours had been saved.

It is just an idea!

JohnF

  • Guest
Re: Why compile Pelles C so slow?
« Reply #13 on: September 01, 2011, 01:41:45 PM »
You only need to rebuild the whole project rarely.

From the help file:

To build the active project, select Build name on the Project menu...

This will build all target files where the source file, or one of it's dependencies, have changed since the last build.


You will find that using Build is much faster than a rebuilding the whole project.

John
Well, why did not I think of it! Sometimes I think too deeply and miss the simple.
Must test it when I get home!
Thank you for teaching me to use my head  ;)  !

Also one can 'compile' individual C units while reducing errors.

John

CommonTater

  • Guest
Re: Why compile Pelles C so slow?
« Reply #14 on: September 01, 2011, 02:31:10 PM »
I have seen similar problems with other developing systems. There should be a document called "New to Pelle-C. Read this first" or something similar.

Actually the help file that comes with Pelles C does give a fair bit of information about POIDE and it's features. 

Help -> Contents -> Contents tab -> Integrated environment

There is also considerable detail about the toolchain.

Help -> Contents -> Contents tab -> Command line tools

And of course the functions library is fully documented, as well.

You should be able to give this a read and discern the differences from what you are used to.

Quote
I based the idea on how I experienced my first contact with the Pelle-C and other development packages changes I made​​. It has always been the same problem with changing the small details here and there. It will be hours behind the forum search function and endless testing before it works without problems.

First contact is often not the best basis for judgement.  In my experience most people spend an inordinate amount of time trying to make the new thing "just like the old thing" and the first reaction is often one of distress over differences.  (In the Retail trades this is called "Buyer's Remorse")  I'd not be making any rash decisions until that phase is passed... Unless you want to re-do your source code *again*.

As much noise as you hear about cross-platform or cross-compiler development from the advocates of "standards" the fact is that when you get invested into one compiler and begin using it's "non-standard" features switching to another compiler is going to mean fixing a lot of stuff.  It's a fact of life in programming and one we all get to live with. 

1 to 2 minutes to compile a megabyte of source code, with a ton of warnings in it, should not surprise you.  Saying that you cannot wait 2 minutes is more than slightly impatient.  Unless you are recompiling the entire project every time you change 1 or 2 lines this should be a non-issue. 

On the toolbar are two buttons "Build" and "Compile"... compile will recompile only the current source page (i.e. the one you've just changed)... There is no reason to build anything until you have an error free compile... so compile your project page by page as you fix problems... then build it only when you are done... The Build button is a smart function in that building only compiles pages that are changed and then re-links the executable... which should greatly speed up the process if you've only altered a couple of lines of code.  (As JohnF has suggested)

So, I guess my second suggestion for you is to spend some time in the help file....


EDIT:
You also asked about other people's compile times... Here's mine...
Size is approx 400k of source code in 8 projects (4 32bit, 4 64bit) including windows resources.
Hardware is an AMD Dual core running 2.6ghz and windows 7 64 bit OS with service pack 1.
Rebuild Workspace: approx 1 minute 10 seconds.
Build after changes: about 9 seconds for my largest project/largest source file.


Not even enough time to scoot to the kitchen for coffee!
« Last Edit: September 01, 2011, 02:49:52 PM by CommonTater »