SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: rowbearto on December 17, 2019, 06:17:06 PM
-
Look for analyzer-openparen-freeze.7z on support.
See the README file to reproduce.
-
I can't seem to reproduce this. Maybe this is being caused by gcc.vtg but I don't know. I also tried to reproduce this on Linux since I've got gcc there and created a tag file for it.
-
It is strange that you are mentioning gcc, because this is a Java program.
-
BTW: I am using JDK 11.0.5 from Oracle. And I am having this issue on Windows, not Linux.
-
Oops. I think I've been working too much. I'll autotag Java.
-
Typing '.' works quite fast for me (always <.5 seconds) and I'm running in a VM with a debug build of SlickEdit. However, typing '(' takes 3 seconds . With a release build on a faster machine, it takes 1-2 seconds to type '('. Not great. If you don't have a SSD, I would expect these times to be much slower than what I'm seeing.
Turn off Java>Context Tagging> "Auto-list compatible parameters" to make it faster.
Turn off Java>Context Tagging> "Show comments" to make it faster.
I think fetching the comments is slow in this case due to the fact that the comment is in "src.zip" which is huge. You can always type "Alt+Comma" when you want to see the comment.
If you turn off Java>Context Tagging> "Auto display parameter information", you won't be waiting for anything. However, it's a sledge hammer approach.
I'm surprised that just displaying the parameter argument information takes so long since listing the members is quite fast.
-
Thanks for the investigation and info Clark! Anything SE could change internally with those options checked to make it faster would be very appeciated!
I like to setup my configuration via scripting instead of checking boxes and then possibly forgetting I did that someday.
How to add into a macro to do each of the 3 below?
Turn off Java>Context Tagging> "Auto-list compatible parameters"
Turn off Java>Context Tagging> "Show comments"
Java>Context Tagging> "Auto display parameter information"
-
Although I don't currently do this, I like rowbearto's idea about scripting config deltas.
I know that it is possible to export a delta (or maybe it is a complete dump, I don't remember) for keybindings.
It might be nice to be able to create (via a similar export feature) a script that would recreate all deltas between a default config and the current config.
Come to think of it, SE must be doing essentially this process during version upgrades (under the covers).
Thoughts?
Sorry for going off topic here. Let me know if I should start a new thread for this.
Thanks
-
I am attaching an experimental hot fix for this problem. Let me know if it helps.
Note, because of the nature of how the cumulative hot fixes are loaded, this fix might be kind of a one-off. You can load it, but it might only be effective for your current session.
If it works, it will be part of the next cumulative hot fix for 24.0.0.
-
Although I don't currently do this, I like rowbearto's idea about scripting config deltas.
I know that it is possible to export a delta (or maybe it is a complete dump, I don't remember) for keybindings.
It might be nice to be able to create (via a similar export feature) a script that would recreate all deltas between a default config and the current config.
Come to think of it, SE must be doing essentially this process during version upgrades (under the covers).
Thoughts?
Sorry for going off topic here. Let me know if I should start a new thread for this.
Thanks
Most options are deltas stored in user.cfg.xml. What we could use is a macro for applying the profile settings in a .cfg.xml file. Should be pretty easy to write. We are already doing something very similar when importing some settings. There are some user.cfg.xml settings that you wouldn't want to apply though (tag files--don't want these for sure, maybe workspace settings, maybe single file projects). Things that references external files are probably not a good idea to re-apply since you are likely to re-apply your settings on a different machine/config directory.
I rarely use the import/export feature in SlickEdit. It is a very easy system for users though. I just save off my user.cfg.xml. Then when I create a new config, I just copy that in. I do have an add on macro I need but I'm using an undocumented plugin system for that. It ends up being an extra invocation argument. Hopefully, some day that plugin system will be fully exposed. I could install the plugin in my config, but that would be an extra step. Instead I invoke SlickEdit via a script and just point SlickEdit to my local plugins.
-
Dennis: Will try the hotfix and let you know.
Clark/Dennis/SlickTeam: For scripting these checkboxes, let me know if below code is correct if so chose to do it:
#include "slick.sh"
#require "se/lang/api/LanguageSettings.e"
using se.lang.api.LanguageSettings;
defmain()
{
// Per language setting.
f := LanguageSettings.getCodehelpFlags('java');
// Java>Context Tagging> "Auto-list compatible parameters" / ctlautolistparams
f &= ~VSCODEHELPFLAG_AUTO_LIST_PARAMS;
// Java>Context Tagging> "Show comments" / ctldispfunctioncomment
f &= ~VSCODEHELPFLAG_DISPLAY_FUNCTION_COMMENTS;
// Java>Context Tagging> "Auto display parameter information" / ctlautofunctionhelp
f &= ~VSCODEHELPFLAG_AUTO_FUNCTION_HELP;
LanguageSettings.setCodehelpFlags('java', f);
}
-
Thanks for the response, Clark
As I said, I don't currently do this (scripting config deltas) but rowbearto's comment kind of sparked a curiosity for me.
One use case I can think of is sharing settings with a colleague, especially as a starting point for introducing a new user to SE with everything set up so that things work the same for them as for me. I suspect that sharing the user.cfg.xml might not be the answer for that scenario. I regret to say that I've not yet managed to create an SE convert so this hasn't been an issue. Still trying (gently).
SE version updates (for the most part) have been pretty seamless for me over the years so I haven't needed the export/import feature much myself, either.
Again, sorry to butt in on this thread. It just got me thinking and wondering.
-
Dennis: Took a look at your hotfix but did not apply it yet.
Your hotfix seems to just apply a timeout. But what if really do want to see the code help and not have it take so long?
Would it make sense to offer an option to have the src.zip unzipped into the tagfiles directory so that unzipping this large file is not necessary every time a '(' is pressed? Then if SE used this unzipped version instead of the src.zip, one would be able to see the comments/code help very quickly and not run up against the timeout and not see it?
UPDATE: When I unzip the src.zip, it takes up 183MB (or 216MB "on disk"). I'd be willing to pay for this disk space utilization in order to get a faster code help.
-
SlickEdit is most likely spending most of the time caching the directory entries in src.zip. There are a ton of files. SlickEdit doesn't load the entire src.zip file. It just loads the directory table, seeks to the one file, and read that one entire file. Unzipping would help the performances for sure.
-
Another speedup maybe could come by caching the directory entries in src.zip only the first time it is read instead of every time one hits '(' ? This src.zip file is not going to change. So if SE has saved this directory cache previously, then it only needs to unzip one file.
Probably not as fast as unzipping it to begin with (which I would love to have), but maybe close enough?
-
There definitely could be better caching. Would be easy to "lock" a zip file cache in memory. Not easy to know when to "unlock" it and free the memory. Might be easier to configure the cache timeout per zip file (maybe keep it for 15 minutes). Right now, once a zip file isn't accessed for about 1 second, then it is closed. That's needed for recursively searching through many zip files and not just keeping all the cached zip files in memory.
-
Dennis: Tried your hotfix, doesn't seem to make any change. I still wait many seconds, and I do see the function parameters and comments.
I used "Load Hot Fix", loaded it, but did not restart SE, and then tried the '('.
-
Another discovery, if I have the following checked:
"Auto-display parameter information"
"Auto-insert matching parameter"
"Auto-list compatible parameters"
It seems that after the '(', the "auto-list" does not work, I don't see any auto-list.
However if I disable "auto-insert", then the auto-list occurs.
I would expect the "auto-list" to work even if "auto-insert" is checked? Is that a bug?
Also, with "auto-insert", the '(' after get inserts "index" which is the parameter name in the prototype of "get", however I don't have any variables named "index" so why is it shown there?
-
Clark: I would propose that for the special case of the src.zip file for Java, to "lock" the cache to it when a Java project is opened, and "unlock" it when the Java project is closed.
If someone opens a Java file without a project, can "lock" it when '(' is pressed, and unlock when SE closes.
I'm guessing this cache may take about 1MB of memory for this file? If that is correct it is a small amount of memory to pay for the speed, assuming it really does speed it up dramatically. Otherwise unzipping during tagging may be better.
-
I did a quick test and hard wire locked src.zip in memory. On my fairly fast machine, saves about .75 seconds. On my VM I'm sure it would save more time.
Here's a work around that saves even more time, you can do yourself, and it's not obvious:
Start a Windows shell as administrator
cd "c:\program files\java\jdk-11.0.5"
mkdir src
cd src
jar xvf ..\lib\src.zip
cd ..\lib
ren src.zip src.zip.old
The above steps will trick SlickEdit into thinking your JDK is configured with actual source and not a src.zip file. You will need to delete your JDK tag file (pretty sure that will force a rebuild). I did this with a clean config and it worked. On my fairly fast machine, saves about 1.25-1.5 seconds. On my VM I'm sure it would save more time.
This testing tells me that it would be best if SlickEdit unzipped src.zip in the users config directory. It's much slower to tag the individual Java files due to the number of file opens required but it's much faster to use it.
-
Thanks Clark!
That workaround does seem to speed things up significantly, but I think I'm still waiting about 1-2 seconds (but much better than multiple seconds).
I will continue working with it to see how I like it.
My jdk src directory is on my C drive, which is an SSD. SlickEdit is on my D drive, which is a 7200 rpm HDD, and the tag files are also on the D drive. Moving SE to the SSD/C drive would present many difficulties for me, as the D drive has my "home" directory that I sync with other computers. Not sure it would pay off much anyway, but maybe.
-
It appears to be the "auto-list compatible parameters" that is causing the remaining few seconds delay. When I turn that off, barely any delay even if I have "show comments" enabled. I turned off "auto-insert matching parameter" as I've found what it is inserting is not really useful.
-
If I have both "auto-insert matching parameter" and "auto-list compatible parameters" checked, there is no delay, however there is also no auto-listing, which I find more useful than the "auto-insert". I think it is a bug in SE that the auto-list doesn't occur in this case as I mentioned in a previous post?
It is only when "auto-list" is enabled while "auto-insert" is disabled that I get the extra few seconds delay, which is a little annoying, but still much better now that the file is unzipped (but I would still like to eliminate it if possible).