Duration of build until simulator shows up

- The system will likely use the most recently installed JRE by default. You can verify this by leaving Java 8 installed, installing Adoptium Java 17, opening a command prompt and typing "java -version".

- JRE stands for Java Runtime Environment. It's the part of Java that allows you to run Java apps on your computer. Typically you have the choice between downloading and installing the standalone JRE or the JDK (Java Development Kit, which includes the JRE.) As an end user / non-Java developer, you would typically select the standalone JRE as opposed to the JDK, simply because it's smaller

I still think it is simpler to only have one JRE installed (Java 17), unless you have a particular need for Java 8. e.g. Suppose you have an app that absolutely requires Java 8 - that would be a valid exception. But again, in general (but not always), Java is backwards compatible.

Today I removed and installed different versions of Java and did a test-build for my projekt "EDGE AllinOne1":
(time from start to the moment the sim shows up)

Eclipse JDK17.0.8_7:  5 min 30 sec    (JDK because I simply accepted the suggestion for my OS)

Oracle Java 8_241:  4 min 35 sec

Oracle Java 8_361: 5 min 00 sec

So, I'll stick to Oracle 8_361.
Maybe the time is "normal", maybe it's the capability of my Laptop, mabe it's my bad coding...  I don't know...

But anyway - a big thank you both for your efforts!

Before you try to build, open the task manager and check the CPU and Memory on your system, and close anything that may be using a bunch of either - browsers etc. There was a chrome update that I got a few weeks back that caused my whole system to slow to a crawl.  If I build/run my most complex app, the sim opens and runs in about 15-20 seconds.

This is the state, when the project is loaded but no build startet.

What me confuses is the "Arbeitsspeicher" (RAM, working memory) is 52% used without any real work...
There is no process in the list down (not visible on the picture) with any notable size!

I've bought the laptop with 8 GB RAM...?

Ok, this is a screenshot of the manager while my datafield is builded...   (seems normal to me...)

mcinner1 said:

What me confuses is the "Arbeitsspeicher" (RAM, working memory) is 52% used without any real work...
There is no process in the list down (not visible on the picture) with any notable size!

What if you click on Details? Are there any hidden processes taking up more memory which don't show up in the normal list?

mcinner1 said:

-Could it be less power of the PC? (Lenovo ThinkPad T570, i5-7300U, 8 GB RAM) 

I have a super old PC that's only used as a server now: i5-2500K, 8 GB RAM. I've never seen build times as long as five minutes for a single device (with Eclipse).

I just tried VS Code with the latest SDK and Oracle Java 8 (update 301). A typical app builds in about 15-20 seconds. And I have 75% memory usage due to other stuff running on the PC.

One thing I have noticed in the past is that exports can be very slow if your project is located on slow storage (like an old flash drive), but I don't think that's relevant to you. You could try disabling your virus scanner during the build to see if that makes a difference.

Ok, I will try…

As I sayd, I‘m new to Monkey C and all about programming I really have learned was MS Visul Basic 6. So, I really know very less about C+. All I did so far was try and error.

Do you think - although you don‘t know my code, which is probably catastrophic in a pro‘s eye - do you think it can be caused by bad coding?
For example: my variables simply are declared as „var xy = nn;“  no privat or public or such else… And there ara many, many variables…

I‘m afraid that the structure of my code is simply primitive

I don't think the structure of your code should make the build 10X slower, to be honest. I'm out of ideas, except trying the build on a faster PC if you have access to one. But again, my old PC is slower than yours and I've never seen a build that slow.

Another possibility is a bug or inefficiency in the compiler. If I'm not mistaken, the compiler uses a 3rd-party parser called ANTLR, which I've used in a project at work which involves a proprietary domain-specific programming language. I found that when ANTLR is run on code of certain complexity, it literally runs forever (well, I stopped waiting after 30-60 minutes.). In that case, I had to rewrite my code to solve the problem.

I'm having a lot of trouble envisioning a Monkey C program that could trigger that kind of problem, though.