Cabbage Logo
Back to Cabbage Site

Editor very slow when csound source code is big

If it can help you, with my csound file (about 1630 lines), in Cabbage 2.0 (on a Windows 10 laptop in power saving mode), there are at least 1 or 2 seconds of lag between a key press and the display of a character in the editor area. But the strange thing is that sometimes I see a similar lag with a little file too… I think there could be something wrong with JUCE editor syntax highlighting routines (or the code that parses a line and display the opcode parameters in the helper bar under the editor area) that put too much stress on the CPU. Or maybe the regular expressions used are too complex. Have you tried to check if the editor control is slow without syntax highlighting or other things activated too?

Actually, this shouldn’t happen. I thought it was just a scrolling thing? I’ll take a look tomorrow.

I tested some of Iain’s largest instruments and I could not recreate this, even with the auto-complete enabled in Cabbage. Even files of over 10,000 lines cause me no issues (apart from sluggish scrolling). The latest Cabbage version is 2.02, is this the one you’re using?

First of all, thank you for your tests.
The version I use is Cabbage 2.0.02 on Windows 10 v1803. The problem of the keyboard lag is the most annoying thing for me.
But now I’m astonished: I tried to delete the “Cabbage2.settings” file to let Cabbage recreate it, but the editor was always slow so I restored the old file with my settings (I use customized colours). Then I tried to change my screen resolution and Cabbage editor was slow as before. Then I tried to change the default GPU associated to Cabbage process (I have 2 GPU: one integrated and another dedicated) but the result was the same. At this point I returned to the original screen resolution I used and the original GPU (the integrated one) association with the Cabbage executable file and… PUFF! Now Cabbage editor is fast in the scrolling and the keyboard lag is gone with the same file that 5 minutes ago was slow as hell!! Honestly, I don’t know what happened… Maybe some bug with the GPU intel integrated driver (but it’s strange that it only affects Cabbage editor)… Now I am curious to see how long it lasts before going back to being slow… :slight_smile:

Me too. Hopefully it’s sorted now :wink:

Try to load the attached file in Cabbage.
Now try to scroll the vertical bar. It should be fast.

Ok, now add a " (double quote) character at the beginning of the file. Try to scroll now…

testText.txt (390.3 KB)

Another test: take the previous attached file “testText.txt” and rename it as a .csd file. Now try to load it in Cabbage… The editing it’s not as fast as when it had a “.txt” extension, but it’s still reasonable.

Now try to add a
/*
at the beginning of the file… The editor becomes much slower than before and if you use a notebook you will notice that your mobile CPU has to increase its frequency to the max only to make you add some characters in the editor at a reasonable speed.

This is the JUCE code editor. It’s always been the weakest component of the JUCE framework. Try building the JUCE demo and doing a similar test in the code editor example. You’ll see the same behaviour. I recently looked into using a different editor with Cabbage, a fast JS editor that I could load in a browser component, but JUCE doesn’t really have very good browser support either. It works, but once the browser has focus, keyboard shortcuts no longer work. It’s a real pity because the current editor is slow.

But I don’t understand why when you load a simple text file in Cabbage, there are some things that get highlighted (and it slows down) if you use double quotes… This is a normal behaviour for the JUCE code editor?

It seems that this is normal behaviour for the JUCE code editor. Try it yourself with the JUCE demo. I did last night and found the same behaviour. I was following this thread for a while. It looked promising but then development seemed to fizzle out. Might be an idea to try it out and see how it compares to the native JUCE component.

A much better programmer than I once tried to embed Scintella into a JUCE project, but had quite a few problems with it.

Do Juce devs know that their code editor component has some serious performance troubles or they are convinced that it has no problems? Maybe we could submit to their attention that file I attached before and see what they say on this matter… I would do it myself but actually I don’t know nothing of how Juce works, so I would be a little embarassed…

[quote=“rorywalsh, post:27, topic:1065”]
A much better programmer than I once tried to embed Scintella into a JUCE project, but had quite a few problems with it.
[/quote]That would be very good. Scintilla is a great and light source code editor component and it’s used by some very nice and efficient text editors (like Notepad++ on Windows, or Geany on Linux/Windows/OSX).

I can ask on the JUCE list. The fact that the issue is present in the demo is enough of a reason to post.

[edit] I just did some tests again with the JUCE demo and it seems that it is the syntax highlighter that is causing the problems. If I remove it the whole thing is very fast…

Thanks for reporting the problem.

Yes, me too think that it’s the syntax highlighter the culprit. It’s always Juce code?

It’s all written natively in JUCE with various calls to the OS. JUCE is, for the most part, an audio framework. These types of component are often neglected in comparison to its other stuff.

More than 1 day is passed and no one replied to your question. That’s strange.

Anyway, from the Juce CodeEditorComponent Class Reference description:

Detailed Description
A text editor component designed specifically for source code.
This is designed to handle syntax highlighting and fast editing of very large files.
                                                   ^^^^            ^^^^^^^^^^

I’m afraid I don’t find it that odd. They’ve never really been big on updating that component. I might try that other editor I linked and see how it performs.

[edit] I tried that editor I linked. It’s not much better :frowning:

They say in the documentation of the Juce CodeEditorComponent that they designed it for “fast editing of very large files”. So, the intentions were good, but… :upside_down:

P.S.: for now, I splitted my big csd file in many smaller files (that I add with “#include …” in the main file). I load in Cabbage only the main csd file which has the <Cabbage>...</Cabbage> section. Then I load all the other files in a fast and light external editor with Csound syntax support.

This is one approach but line numbers for errors get messed up. I really dislike the current editor. I would love to be able to avoid it. Btw, CabbageLite can be used with external editors. That’s the idea behind it.

Yes, but I cannot edit the GUI with the lite version, so I prefer the normal version + external editor.

P.S.: maybe you could add an option to the main Cabbage application, to select with which editor to load a csd file: internal / user selection.

I had that implemented in the last version. I can add it to this one too when I get a minute.