The three most influential factors for Eclipse speed are:
- Using the latest version of Eclipse (2020-06 as on 26 June 2020)
Note that David Balažic's comment (July 2014) contradicts that criteria which was working six years ago:
The "same" workspace in Indigo (3.7.2) SR2 loads in 4 seconds, in Kepler SR2 (4.3.2) in 7 seconds and in Luna (4.4.0) in 10 seconds. All are Java EE bundles. Newer versions have more bundled plugins, but still the trend is obvious. (by "same" workspace I mean: same (additionally installed) plugins used, same projects checked out from version control).
Launching it with the latest JDK (Java 14 at the time of writing, which does not prevent you to compile in your Eclipse project with any other JDK you want: 1.4.2, 1.5, 1.6 older...)
-vm jdk1.6.0_10\jre\bin\client\jvm.dll
Configuring the eclipse.ini (see this question for a complete eclipse.ini)
-Xms512m
-Xmx4096m
[...]
The Xmx
argument is the amount of memory Eclipse will get (in simple terms). With -Xmx4g
, it gets 4 GB of RAM, etc.
Note:
- Referring to the jvm.dll has advantages:
- Splash screen coming up sooner.
- Eclipse.exe in the process list instead of java.exe.
- Firewalls: Eclipse wants access to the Internet instead of Java.
- Window management branding issues, especially on Windows and Mac.
Dec. 2020, Udo conforms in the comments
From version 4.8 (Photon) an up there was a steady speed gain after each version.
The main platform was optimized every release to load faster, enable more features for the dark theme and to add more features for newer Java versions for the Java development tools.
Especially with-in the last 3 versions the startup time was increased a lot. There should be a significant increase in start-up time with the newest version of Eclipse 2020-12.
In my experience it started a lot faster with each new version.
But: There are still plug-ins which do not follow the new way of using the Eclipse API and are therefore still slow to start.
Since the change to Java 11 as the minimum runtime version starting from Eclipse version 2020-09 at least the core system uses the newer features of the JVM. It is up to the providers of the other plug-ins to upgrade to newer APIs and to use the full power of modern CPUs (e.g. concurrent programming model).
Caveat: It is not necessary to put the implementation in the header file, see the alternative solution at the end of this answer.
Anyway, the reason your code is failing is that, when instantiating a template, the compiler creates a new class with the given template argument. For example:
template<typename T>
struct Foo
{
T bar;
void doSomething(T param) {/* do stuff using T */}
};
// somewhere in a .cpp
Foo<int> f;
When reading this line, the compiler will create a new class (let's call it FooInt
), which is equivalent to the following:
struct FooInt
{
int bar;
void doSomething(int param) {/* do stuff using int */}
}
Consequently, the compiler needs to have access to the implementation of the methods, to instantiate them with the template argument (in this case int
). If these implementations were not in the header, they wouldn't be accessible, and therefore the compiler wouldn't be able to instantiate the template.
A common solution to this is to write the template declaration in a header file, then implement the class in an implementation file (for example .tpp), and include this implementation file at the end of the header.
Foo.h
template <typename T>
struct Foo
{
void doSomething(T param);
};
#include "Foo.tpp"
Foo.tpp
template <typename T>
void Foo<T>::doSomething(T param)
{
//implementation
}
This way, implementation is still separated from declaration, but is accessible to the compiler.
Alternative solution
Another solution is to keep the implementation separated, and explicitly instantiate all the template instances you'll need:
Foo.h
// no implementation
template <typename T> struct Foo { ... };
Foo.cpp
// implementation of Foo's methods
// explicit instantiations
template class Foo<int>;
template class Foo<float>;
// You will only be able to use Foo with int or float
If my explanation isn't clear enough, you can have a look at the C++ Super-FAQ on this subject.
Best Answer
Adding an include path to
Project Properties | C/C++ General | Paths and Symbols
only adds the include path to the set of includes searched by CDT's indexer when indexing the project.The actual build system needs to be told the include path by another means. If you're using a Managed Build project (as opposed to a Makefile project) - which it sounds like you are - you would add the include path in
Project Properties | C/C++ Build | Settings
. Note that the indexer automatically picks up build settings, so once you do this, there shouldn't be a need to also add it toPaths and Symbols
.