There's no performance difference at runtime.

Pro:

When doing a full-rebuild of the project, overall compile times will be better (a practice called a "unitybuild").

Cons:

Overall code readability/maintainability will be worse ("oh, that function is on line 103254!").

When making a small change, iterative compile-times will be worse (instead of just recompiling a small part of the project, everything must be recompiled).

what about only one file and no use of classes, that means lots of global variables and functions

This is an interesting question. I've never thought of it before. As was mentioned you may be able to speed up your compile time, but the code will be harder to maintain.

Also, keeping everything in one file, using classes, and using globals aren't related. You can put everything in one file, not use classes and still not use globals. When it comes to classes, you can right fast code that uses classes and slow code that uses classes. This is in the graphics forum so I'm assuming you want to speed up some graphics code. By the question you seem to just be starting out. If you're looking for ways to speed up your code, i'd look for better ways like analyzing code that gets called multiple times in a frame. Writing clean maintainable code will be more beneficial than trying to make the code faster by putting it in one file or using globals.

BTW, when I want to quickly prototype something I kind a put everything in one file, but even in these cases, I have a prototyping framework that I link with it that's not in the same file and linked in. I put things in one file in these situations because I just want to test out something quickly and one file makes sense. Other than in testing situations or when writing small console programs, the benefits of keeping it in one file don't out weigh the cost.

>>Lets say I have made a c++ windows application and I have all the code in just one .cpp file

>>What are the good things and bad things about this, in performance?

as stated above, no difference. you get the same basic exe file irregardless of the number of source files you split the code into.

>>with no use of classes,

>>What are the good things and bad things about this, in performance?

>>that means lots of global variables and functions

>>What are the good things and bad things about this, in performance?

it avoids oo syntax overhead. thats all. i can write the same code as oo or procedural and get it to run at the same speed. the trick is in how you select your objects. basically, you want your OO code to behave just like your procedural stuff, but use the heap instead of the data segment. so each major data structure becomes an object created once at startup. the overhead for creating the object should not be bad compared to the overhead of allocating memory in the data segment at load time. a bit slower perhaps, but you only do it once. from then on, its the same code, but one uses the data segment, and one uses the heap. since both are essetially "static" data structures, that you don't new and release, you have no heap related overhead or other heap issues. stay away from templates and other generic code that does runtime type checks, and thats pretty much it. OO encapsulated procedural code running off the heap instead of the data segment, just as fast as procedural with globals - down to the clock cycle. again the trick is to understand what the OO syntax does, and more importantly what it does that you don't need and should therefore not use it in "critical section" code. in non critical section code, the benefits of OO syntax (if required) definitely outweigh the slight performance hit. Note that i say if required. not all projects require the extensability and reuse and other benefits that OO syntax provides. for a big company with big projects and big teams, such language capabilities are indispensable. for a single small project and a lone developer, they may be of little practical use - IE overkill.

that should answer your questions re: performance.

however, as stated above, issues of readability and maintainability can crop up if the code is poorly designed or poorly organized. i currently split games into 4 modules: game, game library, audio library, and built-in modeler/animation editor. On my Caveman project the game source file is about 80,000 lines of code. Intellisense is slow - or non-existent. I now do my coding in CScript and then run CScript to generate the C++ code, so i don't miss intellisense(less). A release build takes 55 seconds to link. but technically, that has nothing to do with the number of source files, its just a big game. inside the game source file, is actually a series of source files one after the other. so everything is organized into nice modules with clean API's, just like objects. they all just appear one after the other in the same file, that's all. good api design is the key to well organized and well designed code, irregardless of syntax. of course it helps that i'm the only coder, so no issues with lack of code familiarity with the developers. even so, i keep my api's well documented, and have source access if there's a question as to the behavior of a function.

then of course there's the danger of misusing globals. again this comes down to good api design, good docs, and coders who know how to use the api correctly. almost any code can be misused. where and how the variables it uses are stored makes little difference. globals perhaps suffer more misuse due to their scope.

Which are the advantages of a giant single room apartment over a more traditional one? Sure, you gain some space (no walls), but you loose privacy, rational furnishing, comfort ...

Honestly, I don't see any real reason to write a (non trivial) application in a single file (I'm scared by the maintainance nightmare I would eventually address)