Pelles C forum
C language => Expert questions => Topic started by: linnar 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?
-
Turn off all optimizations and try it again... Optimizing compilers are often slower because they do a lot more work for you.
-
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
-
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 (http://www.firmabok.com)
Sorry for my bad English!
-
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 (http://forum.pellesc.de/index.php?topic=3250.msg13922#msg13922)
For example:
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:
-
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...
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...
#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.
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" ...
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.
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...
-
Thank you all!
I have read everything but do not have time to comment on the now.
This sounds most correct:
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!
-
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
-
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.
-
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
-
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!
-
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 ;) !
-
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!
-
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
-
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.
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!
-
@CommonTater
Wise words!
I will do as you write and like any other type.
I know I get impatient when I do not get it to work. I've been through it before. I think really give PellesC a Change.
An intermediate step is to use PellesC editor to LccWin32 for the program I'm doing now and then move on when I start the new program.
I will come back and write how it goes.
-
Ok, if you're going to use LCC under POIDE you may find my Quick Flags addin to be useful along with Timo's multi-compiler tool. QF lets you manually edit the command line flags for the toolchain... Useful since LCC and POCC flags are different.
Best of luck with it...
-
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.
I have been running the program! I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
When I work in my program compiled with Pelle-C gets it wrong every time I get date time, the program dies with the error message from Windows:
LPSTR charDateFBS;
//Get the date
charDateFBS=ac_ClockGetLocalTime_1("YY_MM_DD", "-");
Use PellesC with LCC-Win32's lib.
It did not work!
Timo's little program "Select Compiler" I understand me not to. I have entered all of LccWin32. Nothing happens when I click on the button. A small window "Wait for the Testing" is open and doing nothing. Does anyone know how to do?
-
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.
I have been running the program! I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
When I work in my program compiled with Pelle-C gets it wrong every time I get date time, the program dies with the error message from Windows:
LPSTR charDateFBS;
//Get the date
charDateFBS=ac_ClockGetLocalTime_1("YY_MM_DD", "-");
I take it the ac_ClockGetLocalTime_1 is a self-written procedure... which is going to need debugging.
Take a look at the Help File -> time.h header... There are several time functions there you may be able to use to advantage.
The most likely problem you're running into is that LCC is not a standards driven compiler where Pelles C is... many of LCC's library functions may be differently named or simply not present on Pelles... This is the big problem with non-standard code, you end up with a mess that does take some time to clear up. BUT, once you're over that hump now, moving to the "next better tool" will be far easier...
-
I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
Use Define compatibility names (-Go)
Timo's little program "Select Compiler" I understand me not to ...
Have you copied SelCompiler.dll to PellesC\bin\AddIns-folder ?
A small window "Wait for the Testing" is open and doing nothing. Does anyone know how to do?
Are you running that SelCompilerDlgTest.exe ? It for testing those dialogs only.
-
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.
I have been running the program! I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
When I work in my program compiled with Pelle-C gets it wrong every time I get date time, the program dies with the error message from Windows:
LPSTR charDateFBS;
//Get the date
charDateFBS=ac_ClockGetLocalTime_1("YY_MM_DD", "-");
I take it the ac_ClockGetLocalTime_1 is a self-written procedure... which is going to need debugging.
Take a look at the Help File -> time.h header... There are several time functions there you may be able to use to advantage.
The most likely problem you're running into is that LCC is not a standards driven compiler where Pelles C is... many of LCC's library functions may be differently named or simply not present on Pelles... This is the big problem with non-standard code, you end up with a mess that does take some time to clear up. BUT, once you're over that hump now, moving to the "next better tool" will be far easier...
ac_ClockGetLocalTime_1 I have written. It is a feature of about 830 functions I wrote to speed up the work. I started developing my function libraries with Symantec C (/ C + +) which is the predecessor to Digital Mars. When I went over to LccWin32 so did all the features of my library without any problems. If I should continue with Pelle's C-I have to write about a lot of code.
I intend to continue to debug all the code in the Pelle-C from time to time to ensure that the code works in most compilers, but I do develop in LccWin32.
Pelle-C is the most slow tool I've tested in recent days. I simply do not have time to sit and wait up to one hour per night on it to compile. If I compile 30 times in one night, it takes a total of 1 minute and 30 seconds in LccWin32. With Pelle-C, it takes 60 minutes. With the others I tested, it takes between 10 minutes and 20 minutes.
-
Well, I will give you that Pelles is a bit slowish compiling, but in my case that's far less of a concern than the end result... I just grab a coffee or go pee (two events that may be connected) while it's chunking away.
I do understand that conversion between libraries and compilers is a bit of a burn out... but I wouldn't write Pelles of for any new projects you're starting... Thing is, for what I do (mostly small to medium projects and one-offs) it's never been anything but 100% reliable... which is more than I can say for VC++ or MinGW.
I wish you luck on this... It's kind of a shame the conversion didn't go as planned.
-
Well, I will give you that Pelles is a bit slowish compiling, but in my case that's far less of a concern than the end result... I just grab a coffee or go pee (two events that may be connected) while it's chunking away.
I do understand that conversion between libraries and compilers is a bit of a burn out... but I wouldn't write Pelles of for any new projects you're starting... Thing is, for what I do (mostly small to medium projects and one-offs) it's never been anything but 100% reliable... which is more than I can say for VC++ or MinGW.
I wish you luck on this... It's kind of a shame the conversion didn't go as planned.
Do not worry, Pelle-C is the best of the tools I tested. I am not leaving! Have already begun to explore why it is slow. I run a couple of other programs in the background while working, so early, it looks as if it's editor who takes very good time to get started. Then the compiler very much power from the CPU. My CPU goes up to the ceiling and stay there long. All other programs will slow down the speed while compiling. In addition, the final binary file smaller than I've seen with any other compiler. If the compiler does not optimize the code so effective, it would instead compile faster, much faster, I think. The editor should be speeded up. I think it does more than to be an editor.
-
I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
Use Define compatibility names (-Go)
OK! Thanks for the tip!
Timo's little program "Select Compiler" I understand me not to ...
Have you copied SelCompiler.dll to PellesC\bin\AddIns-folder ?
Uups, I had missed that small detail!
A small window "Wait for the Testing" is open and doing nothing. Does anyone know how to do?
Are you running that SelCompilerDlgTest.exe ? It for testing those dialogs only.
Hmmm, I chose it because it was already entered data for the compilers that I have. Believed that the "test" still worked.
I'll get what you have described and returns when it works. It would be great if I could use Pelle's editor to LccWin32!
-
Ok... maybe some simple direction on setting up an add in would help...
Addins are DLL files that get parked in the bin\addins directory for Pelles C ... usually at
C:\program files\Pelles C\Bin\Addins
There are two flavours... If you are running the 64 bit version of POIDE use the 64bit DLL... otherwise use the 32 bit one. So exit POIDE and drop the DLL into the folder then restart POIDE...
Now go to Tools -> Customize -> Addins and check the box beside the addin to enable it and OK your way back to the main window.
Next go to Tools-> Options -> Addins and click the addin... then the options buttons....
It's Timo's addin so I'll feel more comfortable if he takes you through the setup...
-
I have tested "SelCompilerDlgTest.exe" named "SelCompilerWS-1.2"!
- It worked fine with adding it to the Pelle-C
- Click on the menu for SelCompiler
- It opened a small window with the "PellesC" and "Options ..."
- It also opened a dialog box that says "Wait for the Testing".
- I clicked on the button
- Click "Options ..."
- A window was opened
- Click the "New"
- I entered all the data for LccWin32
- Click the "Save"
- Closed down SelCompiler
- Opened SelCompiler again and there were no new button with the name I wrote in and everything I typed was gone.
Which version should be used?
I've found:
SelCompiler_WS-3.zip
SelCompiler_WS_9.zip
SelCompiler.zip
SelCompiler-1.1.zip
SelCompilerWS-1.2.zip
EDIT:
OK!
I have it!
It must click "New" before clicking "Save".
It gets a little illogical at first look but then I understand what is meant by "New".
Now I do other things, will return in a few hours when I have time to test!
-
The "selcompilerdlgtest.exe" file is only a test platform for the dialog itself. It is NOT an active addin...
Follow the steps I outlined...
If you have further questions, I'm sure Timo will help...
http://forum.pellesc.de/index.php?topic=3250.msg14561#msg14561
-
It must click "New" before clicking "Save".
It gets a little illogical at first look but then I understand what is meant by "New".
OK. changed to save too.
-
The "selcompilerdlgtest.exe" file is only a test platform for the dialog itself. It is NOT an active addin...
Follow the steps I outlined...
If you have further questions, I'm sure Timo will help...
http://forum.pellesc.de/index.php?topic=3250.msg14561#msg14561
Everyone has the word "test" in the name.
There is a variant that has the word "test" but it has none .exe-file so I imagine that it can not be used.
-
linnar... are you reading the instructions Timo and I have given you?
*There is no executable file*... it is a DLL file that is placed in a special folder so that it is loaded by POIDE (Pelles C editor) and works from inside the editor... hense the name "Addin"...
Go take a look at my QuickFlags addin... there's no exe file there, either.
-
linnar... are you reading the instructions Timo and I have given you?
*There is no executable file*... it is a DLL file that is placed in a special folder so that it is loaded by POIDE (Pelles C editor) and works from inside the editor... hense the name "Addin"...
Go take a look at my QuickFlags addin... there's no exe file there, either.
Well, I've read the link several times.
I'm not one hundred percent in English, I can sometimes misunderstand. I understand now that it's dll file to be included. I thought it was a exe file.
Sorry for this!
I'll try it again!
-
If in doubt check the project settings for the type of executable to be created by it.
It is even easier, if you just build the project.
-
Now it works!
Thanks to you who built this fine little program, and thanks for your help!
I get some strange error messages but it may be because I have included some other lib to my program to work.
Also need to change / add some other compilation instructions.
A rebuild took about 10 seconds. (before 120 sec)
To be continued ....
-
There are some problems left to solve! I know, for example, not what all the acronyms in "SelCompiler" means.
I'm not getting the icon in the program.
Get new error messages that Shell.lib is when I have it with, etc.
A bug in "SelCompiler":
When you press the "Delete" in the Options but regrets it and press the "Cancel" it is still all erased when you open the "Sel Compiler" next time.
Next time I mess with this, I enter everything again .... >:(
-
I know, for example, not what all the acronyms in "SelCompiler" means.
These are variables for poide.exe and pomake.exe:
CC: compiler executable
CCFLAGS: compiler commandline options
AS: assembler executable
ASFLAGS: assembler commandline options
LINK: linker executable
LINKFLAGS: linker commandline options
RC: resource compiler executable
RCFLAGS: resource compiler commandline options
AR: library manager executable
ARFLAGS: library manager commandline options
INCLUDE: include search paths
LIB: library search paths
Title: name or title for SelCompiler option block
- name when using New button
- title when using Save button
A bug in "SelCompiler":
When you press the "Delete" in the Options but regrets it and press the "Cancel" it is still all erased when you open the "Sel Compiler" next time.
Cancel button removed.
-
@timovjl
Thanks for your nice and quick response. Nice to have developers that listen to users, and change it as noted.
Great!
-
Is this what is the answer to the hugely short compilation time?
From LccWin32 website:
The 'windows.h' file, is only about 400K, instead of more than 4MB in other systems. This speeds compilation enormously.
source:
http://www.q-software-solutions.de/products/lcc-win32/components.shtml (http://www.q-software-solutions.de/products/lcc-win32/components.shtml)
LccWin32 website:
http://www.q-software-solutions.de/index.shtml
-
The windows.h with Pelles C is only about 3k. Mind you it includes a lot of other files...
There is a "trim down"... #define WIN32_LEAN_AND_MEAN ... which loads only the most basic of the sub-headers but it still probably totals a megabyte or so.
Yes this will make a difference... but most likely the largest difference is that Pelles C is an optimizing compiler where LCC is not. Reworking and optimizing source code takes time.
-
Once I tested Lcc-Win32 using the PellesC headers, Lcc-Win32 was then the same speed as PellesC.
It was a long time ago however.
John
-
The windows.h with Pelles C is only about 3k. Mind you it includes a lot of other files...
There is a "trim down"... #define WIN32_LEAN_AND_MEAN ... which loads only the most basic of the sub-headers but it still probably totals a megabyte or so.
Yes this will make a difference... but most likely the largest difference is that Pelles C is an optimizing compiler where LCC is not. Reworking and optimizing source code takes time.
LccWin32 has an optimization option (-O). I have not used it on my big projelt of 1.2 Mb. When I get time I will test the flag and see if it takes longer.
-
Once I tested Lcc-Win32 using the PellesC headers, Lcc-Win32 was then the same speed as PellesC.
It was a long time ago however.
John
When I compare the compilation time for smaller projects, the difference is not great. A code of 10k takes under 0.1 seconds in LccWin32 and one sec in Pelle-C.
LccWin32 always print compilation time but it does not Pelle-C so it is difficult to measure the compilation time for Pelle's C-exactly when the time is down to one second.
-
Can this help timing?
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>
int main(int argc, char **argv)
{
STARTUPINFO si;
PROCESS_INFORMATION pi;
FILETIME ftCreationTime, ftExitTime, ftKernelTime, ftUserTime;
SYSTEMTIME stTime;
long long ll, *pLL1, *pLL2;
char *lpszCmdLine, *pChar;
pChar = GetCommandLine();
if (*pChar == '"') {
pChar++;
while (*pChar && *pChar != '"')
pChar++;
pChar++;
} else {
while (*pChar && *pChar != ' ')
pChar++;
}
while (*pChar && *pChar <= ' ')
pChar++;
ftExitTime.dwHighDateTime = 0;
ftExitTime.dwLowDateTime = 0;
memset(&si, 0, sizeof(si));
si.cb = sizeof(STARTUPINFO);
if (CreateProcess(NULL, pChar, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi))
{
WaitForSingleObject(pi.hProcess, INFINITE);
GetProcessTimes(pi.hProcess, &ftCreationTime, &ftExitTime, &ftKernelTime, &ftUserTime);
CloseHandle(pi.hProcess);
CloseHandle(pi.hThread);
ll = *((long long*)&ftExitTime) - *((long long*)&ftCreationTime);
FileTimeToSystemTime(((FILETIME*)&ll), &stTime);
printf("%d:%d.%d %lld\n", stTime.wMinute, stTime.wSecond, stTime.wMilliseconds, ll);
} else printf("error\n");
return 0;
}Or AddIn ?
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <addin.h>
static HWND g_hwndMain = NULL;
BOOL WINAPI DllMain(HANDLE hDLL, DWORD dwReason, LPVOID lpReserved)
{
return TRUE;
}
ADDINAPI BOOL WINAPI AddInMain(HWND hwnd, ADDIN_EVENT eEvent)
{
TCHAR szTmp[100];
static DWORD dwStart, dwEnd;
switch (eEvent)
{
case AIE_APP_CREATE:
g_hwndMain = hwnd;
return TRUE;
case AIE_PRJ_STARTBUILD:
dwStart = GetTickCount();
return TRUE;
case AIE_PRJ_ENDBUILD:
dwEnd = GetTickCount();
wsprintf(szTmp, "%dms", dwEnd - dwStart);
AddIn_WriteOutput(g_hwndMain, szTmp);
return TRUE;
default:
return TRUE;
}
}
-
@timovjl
Wow, AddIn version I like ;) !
Right now I am busy with other things, but I will try your suggestion to code when the time for there.
(Developers' right now the graphical shell to my accounting software. )
EDIT:
Got a few minutes ago found out that I can get the source code to LccWin32 editor "Wedit" if I want to develop it into something more modern. 8)