PureBasic Forums - English

Regarding speed of compile, I'm very happy with it. I've just compiled my project of more than 152000 lines in 5 seconds (approx). The compiled executable is about 5Mb. The project has been converted (and enhanced significantly) from VB6, and compiling the original version in VB6 on the same machine takes about 25 seconds and produces an 8Mb executable.

I think you're comparing PB compile to VB6 run/interpret?
~20k lines in VB6 took at least 3 minutes to compile an executable, where PB is close to 15 sec.

On my Win7 machine (4GB, 2.27GHz dual core) at takes VB6 about 25 seconds to 'compile to native code' my old VB6 project.

However, my point is that with my project, compiling in PB is much faster, and with this crude time estimate (based on watching the second hand on my watch) VB6 takes about 5 times as long to compile as PB.

Ok. I like this discussion, its about making PB better and better (its already in awsome status...). I started it, and next time i compiled i got a out of memory. well. a reboot and now i compile in 1 second. Not on the mac though where its 15 seconds, which is enough time for me to read the newspaper, take a dump and look at facebook...

On the mac, we use the build in assembler 'nasm' instead of 'fasm' (which is know to be the fastest assembler around) which could be the difference between mac and windows.

Fred wrote:On the mac, we use the build in assembler 'nasm' instead of 'fasm' (which is know to be the fastest assembler around) which could be the difference between mac and windows.

Fred,
are there any plans to move away from fasm on the other platforms?

Creating proper static libs instead of using TailBite comes to mind...

bye

Nowhere in this thread is any specific information about the sources being compiled and what they're actually doing. Therefore, claiming PureBasic to be "slow" at compiling is misleading and possibly off-putting to potential buyers who may be lurking. Saying something is "slow" without details is totally unfair. It could even just be your PC for all we know.

So, I say: give us more specifics about your sources, Jesper, and what they're doing. What files they're including, and whether they're being generated by a pre-processor, and whatever else is relevant. Your PC's stats. Are you running an anti-virus, etc. Not just "it's slow, can you make it faster".

You said your sources are around 30 KB and you have time to read this forum during compilation. That points to something else being the bottleneck, and not the compiler. For comparison, I have an old dual-core PC running Win XP and I can compile a 568 KB source in about 3 seconds, and that's with my source also including another 12 KB source, and also including 70 x 2 KB icons and 5 x 3 KB wav files. That ain't slow to me by any stretch of the imagination.

I love PB.
My inital question was what is it that takes time to compiler? Is there any bottleneck that can be avoided?
Like if I could speed up using a RAMdisc instead of normal disc?
Like if I could preload something that would speed things up?
I saw this thread as more a discussion on what I could do to speed up my system.
I think we got some good ideas here - precompiling parts of my libraries etc.
I might do some tests with RAMdisc instead of normal disc for temp and compiler...
PB rocks !

There are several steps for a compiler, and the number of steps varies depending upon the complexity. Each step consumes time. They are not merely "lookup tables".

I'm guessing that PB is a recursive descent, which is the easiest to write by hand. The first step it does is recognize the "words" in the file. This is called tokenizing. For instance, when it first opens the file, is the first character it sees a semi (comment), a hash (constant), or a letter (var or func call)? Some tokenizers read a whole word (characters until a "separator" char is found). After the word is tokenized, the compiler determines what to do (skip the comment, use the constant, or call the func). During this final handling, "output code" is produced. More sophisticated compilers use an intermediate code so it can be optimized more efficiently after code generation has completed. There is reason to believe that PB just goes straight to asm. The compiler just repeats these steps until the file is done.

A more complicated compiler may run multiple passes on the input file. For instance, a two-pass compiler might use the first pass to recognize all of the variables and constants, and a second pass to do the rest. This allows for referencing a function or constant that has not yet been defined, or implementing a preprocessor as in C.

A common next step is the optimizer, if the system has one. I can't tell if PB has one or not; it may simply have efficient asm output, or it may run a rudimentary optimizer. Just like compilers, optimizers vary greatly in complexity; some run in one pass, some in two or more.

Next comes the assembling. This is basically done the exact same way as compiling, except assemblers are much less sophisticated (they have fewer rules, and tighter constraints) so it can go faster. Also, instead of readable code for output, the assembler generates binary code. Assembling is simple enough that it can merely be a lookup table type program, although they are generally not.

Just as a "gut feel" comparison, I am guessing that the Gnu Assembler takes about 5 times as long to assemble a file as the Fasm assembler that PB uses. I don't know why it is so slow, but I can tell you that it is horribly inefficient with macros.

Anyway, back to your "how can I make it faster" question. In reality, aside from precompiling libraries, there is not much you can do. That will save you from repeatedly compiling code that is not being edited.

Kuron wrote:Exaggerated compile times are usually down to a nefarious AV (or other such program) trying to do things it should not be doing.

I agree, that and badly setup computers. That must be the case here as both Visual Studio (2010) and PB compiles in a few seconds under correct conditions.

X wrote:

Kuron wrote:Exaggerated compile times are usually down to a nefarious AV (or other such program) trying to do things it should not be doing.

I agree, that and badly setup computers. That must be the case here as both Visual Studio (2010) and PB compiles in a few seconds under correct conditions.

Not on OSX - without any AV or such, obviously.

Polo wrote:Not on OSX - without any AV or such, obviously.

What does OSX have to do with the OP who is complaining about the compile time on his new i7 laptop?

The only mention of a Mac is in comparing compile time of the new system to his old Macbook.

Not a lot can be done for suggestions since the OP is not telling us which version of Windows he is running on his new system.

Well. No this was my fault. If I get a windows computer and dont reboot it in two weeks everything will be slow - i rebooted and its all good.
The macbook air however (core2) is slow. This however was very good explained before - using nasm instead of fasm. I think xcode probably also play a role here.
Tenaja had a great post on the steps on compiling. Working with strings is slow, no doubt about it. I remember GFA32 usually saved the source as a binary code instead of the actual string (like messagerequester would not be that but INT(1049) or something in the binary file). However I am glad PB doesnt do that due to compatibility and future uses.
Putting compiler and stuff in ramdisc would not be an option on macbook air, since its already SSD. I has been going slower and slower lately. I might just look into what I can do to speed the MBA up, its proably a general computer thing.

jesperbrannmark wrote:I might just look into what I can do to speed the MBA up, its proably a general computer thing.

Being a Mac, it probably doesn't have enough RAM in it.

I can't speak for the Mac version of NASM, but on Windows, NASM is not a bottleneck. I have been using one language for years that uses NASM. Very speedy compile times.

FASM on OS X seems to be possible but complicated
http://board.flatassembler.net/topic.php?t=9954