VS Code extremely slow

Team,

I was full of hopes trying to follow the installation instructions to start developing.

Not sure why you killed the Eclipse version and switched to VS Code which I hate to the bone because it's not even a joke of an IDE.

Now, I'm trying to generate the very basic watch face project.
Build time takes forever (more than 3 min).
Simulator start takes forever (more than 3 min).
If I need to make any change in the code it takes forever to reload the project (another 3+3 min?!!! are you kidding me?)

I'm on a Win 11, 32Gb RAM, Core i7 13 gen... What gives?

Thanks.

P.S. I have no idea on how to navigate the code or see any code completion in the editor. I have no idea on how to do ANYTHING in this stupid VS Code. Why on earth did you decide to torture yourself?
P.P.S The way 'documentation/guides' are written is another joke.

Top Replies

All Replies

  • I was on 1.8.0_442. Can try to do the latest 1.8 build and report back.

    Yes, I made a typo (MonkeyC is 1.2.2, of course). Apologies.

    How do I get the 'continuous' build?
    Is it anywhere in the documentation? So far I had to stop the sim, then stop the debug in VSC, then make changes, then [painfully] rebuild the project for several min, then wait [painfully] for another several long min for the sim to start etc...

    And no, no language features are available (I don't see any help in the editor for code completion, method names in the classes referenced etc) - nothing. The 'ctrl+mouse hover/click' doesn't even work.

  • I was on 1.8.0_442. Can try to do the latest 1.8 build and report back.

    So, you mean you tried both Amazon Corretto 21 and 1.8.0_442?

    Can you try https://adoptium.net/ (Temurin 21)? Since it's also based on OpenJDK 21, I don't see why it would be significantly different than Corretto 21, but at least I know it works for me.

    How do I get the 'continuous' build?

    This continuous build automatically happens in the background to support the language features, after you've built the project manually once. The extension runs a process called a language server builds the project whenever you make changes in order to support language features. The IDE communicates with the language server to provide language features.

    Again, it doesn't affect the usable build artifacts for your project in the bin/ directory. When you make changes that you want to test/debug, you need to build the project manually (either using the "Monkey C: Build Project" command, or by running the project).

    Again, if the build takes several minutes to complete, it's not surprising to me that the language features don't work.

    - if you even change one character of source and save the file, the language server will rebuild your code

    - the language server will always want to work with a build that corresponds to the latest version of your code, so while the code is building, I would expect language features not to work

    - if the build takes 3 minutes (for example), then I would expect language features to not to be available for at least 3 minutes

    - but if you are constantly changing your source, then the language server would never be able to "catch up" with the latest version of your source

    Ofc the obvious objection to my guess above is that you may stop changing your source for extended periods of time, yet the language features still don't work, so what I said can't be the full explanation. Another guess I could make is that the language server times out if the background build takes too long?

    You could try to debug the language server by opening the Output tab and selecting Monkey C Language Server as the output source. I see output like the following when the language features are working:

    [Info] Workspace created for root folder '.../dev/TestDFX'.
    [Info] Recieved textDocument/didOpen notification for URI 'file://.../dev/TestDFX/source/TestDFXView.mc'.
    [Info] Found workspace with root folder '.../dev/TestDFX' for file '.../dev/TestDFX/source/TestDFXView.mc'.
    [Info] Building full workspace for root folder '.../dev/TestDFX'.
    [Info] Workspace initialized for root folder '.../dev/TestDFX'.
    [Info] Building full project for root folder '.../dev/TestDFX'.
    [Info] Building full namespace for root folder '.../dev/TestDFX'.
    [Info] Full workspace build successful for root folder '.../dev/TestDFX'.
    [Info] Received textDocument/documentSymbol request for URI 'file://.../dev/TestDFX/source/TestDFXView.mc'.a

  • where would I see this output?

  • - Open the output view:

    CTRL-SHIFT-U 

    or

    CTRL-SHIFT-P > Focus on output view

    - Click on the output source dropdown and select "Monkey C Language Server"

    I believe you should see output here without any further configuration. 

  • This JDK didn't help at all.
    Still MINUTES rebuilding and MINUTES starting the emulator.
    Extremely frustrating.

    Also, is it supposed to dynamically update the code so that I can see changes in the emulator immediately?

  • This JDK didn't help at all.
    Still MINUTES rebuilding and MINUTES starting the emulator.
    Extremely frustrating.

    Hundreds (?) or thousands (?) of people aren't experiencing this. That is, your issue isn't general.

  • This is not particularly helpful, tho.

  • I turned off type checking by adding

    project.typecheck=0

    to the monkey.jungle file, it improves performance a lot for me, I guess it would not make a big difference with regard to your issues, but it might be worth a try.

  • What I would like to be able to do is turn off background compiling, and just compile when I say. Meaning revert to pre SDK 8 behavior. What I would also like is for Garmin to spend less time on what they think we might want, and spend time on things we actually ask for, like bug fixes. Was there a lot of clamoring for "recompile the whole project on every keystroke" and I just missed it?

  • Also, is it supposed to dynamically update the code so that I can see changes in the emulator immediately?

    No, to see changes reflected in the simulator (*), you have to explicitly run the project. (Which ofc triggers a build if your source code has changed.)

    (*) It's important to realize the simulator is not an emulator as there are several differences compared to real devices, especially when it comes to bugs - some bugs are in the sim and not the real device, or vice versa.

    Still MINUTES rebuilding and MINUTES starting the emulator.
    Extremely frustrating.

    That does sound frustrating. You might want to post in the CIQ bug reports forum, hopefully someone from the CIQ team can be of assistance.