I agree to Idea Focus more on editor performance
Voting Disabled

23 votes

I disagree to Idea Focus more on editor performance

Rank39

Idea#550

This idea is active.
Editor »

Focus more on editor performance

Focus more on editor performance and help us more easily find the settings related to editor performance. Each major version of Toad brings a slower editor. As much as I like Toad, with version 11, I am beginning to seriously consider dumping Toad due to the extreeeeeeemely annoying editor lags.

I don't need idiot features as much as I need to be able to type quickly as well as to cut and paste from the keyboard and number pad quickly (remember SAA CUA?).

The only good news with version 11 is that the screen flickers with each keystroke from older versions appears to be gone. With previous versions, Toad was getting unbearable on my P4 machine, then, fortunately, the company recently gave me a Core2 Duo machine which made newer versions of Toad bearable even with the screen flicker. But Toad 11 is just hopeless.

I have most features related to editor performance turned off including Code Assist, Check Rules as You Type, and the Navigator (sadly), and still it is ugh. Some here have reverted to older Toad versions due to editor performance.

One thing I would like in particular is to turn off the auto-refresh of the Navigator. The Navigator is very handy for working on large packages (I set it to display only procedures and functions). But not only does the auto-refresh feature in the Navigator cause annoying editor lags, it also makes the Navigator useless for jumping around a package in the middle of an edit (because an edit usually is not compilable until finished and this causes the later procedures to disappear from the Navigator). Help indicates that the Navigator refreshes when you hit the refresh button or save the file. It does not mention this silly auto refreshing. Add an option to bring back only refreshing on demand. Please. Pretty please? Do I really need to split this of into its own idea?

Submitted by 2 years ago

Comments (9)

  1. Moderator

    The auto-refresh of the navigator occurs in a background thread. You will notice increased CPU usage if you were to stop typing and look at Task Manager, but the population cancels almost immediately as you start typing again. Any delay that you notice is most likely not related to the background parsing. In addition, the navigator population is a nice side effect of another necessary action, parsing. Parsing is a necessary evil. Without it most of the Editor functions are dependent upon the parsing results. Background processing uses only CPU cycles that your machine can part with. There is no harm in high CPU utilization unless another thread requires them and they aren't available. The background parsing uses a low priority thread so Windows will allow other processes to use CPU as they require it. It's non-blocking CPU hog.

    Other performance issues. Toad 11.1 is underway and we have begun some major work in the Editor and it's processing of parser results. The background thread is still there, but there were several memory leaks that were addressed that caused Toad 11.0 to bog down over time. Things will be better in this area. Memory use during and after a parser should both greatly be improved.

    You wrote: "it also makes the Navigator useless for jumping around a package in the middle of an edit"

    Even without the background parsing the Navigator will still be non-functional without parser results. If your edit has modified the length or position of any text then old parse results are not located at the same location they were previously so clicking on stale items in the Navigator will still not work properly. With the exception of very large packages the navigator should catch up to your edits in a matter of seconds. In Toad 11.0 a test package I'm using takes ~30 secs to parser. In Toad 11.1 it's taking ~6 after improvements. The package is 20,000 lines long. You should see improved performance here.

    Other performance tweaks would be to disable all of the Code Assist options as you've done. Others would be to trim the PL/SQL language down to the smallest set of items you can live with. See Options|Editor|Behavior. Click the '...' button next to the dropdown for the PL/SQL language. All of those items on the syntax highlighting tab will cause delays. If you can live without most of those then you'll see improvements. In particular the items dealing with dynamic highlighting like the rules that highlighting matching BEGIN..END blocks and IF...END IF blocks for instance. The syntax highlighting is cause for most performance issues with large text. You can confirm if you have an example that is slow, right-click in the Editor and choose the Plain Text item under the Language/Syntax Highlighter menu item.

    Finally, tab changes are slow because I can't seem to get support for going to a single tab style. The various tab styles for SQL, PL/SQL, and Plain Text kill performance. We have to maintain, in memory, a complete structure representing the layout of your Editor desktop and save/restore it on each tab change. This is huge. In Toad 11.0 beta I introduced an alternate method that used a single dock layout for all tabs. I was able to load hundreds of files into one editor without crashing. A file that was split over ~100 tabs loaded in < 10 secs. It was amazing. Users do not want this though. The vast majority of comments were in favor of distinct tab styles for working with SQL and PL/SQL code so I had to pull that work out.

    2 years ago
    0 Agreed
    0 Disagreed
    1. Moderator

      Ignore the apparent lack of newlines. Arghhh! Idea Pond stripped my newline formatting, sorry.

      2 years ago
      0 Agreed
      0 Disagreed
  2. matthew_jernigan Idea Submitter

    Michael, that was an awesome response. It is not often that someone reads my entire comment and responds to all of it. (BTW, your newlines were not in the email but I do see them on the web page.) The slow tab switching doesn't bother me so much which is why I didn't mention it. Regardless, that is still interesting information to put in the back of my head. I hear you about the single tab style but I must admit that something such as setting the Navigator to display on some tabs and not others is really useful. This is the only thing I use tab styles for but it works well that way. It would be nice to be able to set the results grid a different size for each tab as well, but I'll take what I can get. You see, some of my tabs contain package code, some contain queries that I'm tuning, and some contain miscellaneous scratch. Each needs as much real estate as possible so I'm always pushing the results grid around or hiding it.

    Anyway, back to the point. I can't wait to see 11.1 given what you said. It sounds promising. Regarding the Navigator, I understand what you said about the need for parsing given all the features it provides for, but it seems to me that a middle solution could still be found. For example, I would be perfectly happy with clicking on stale items in the Navigator that didn't quite take me to where I want. Close enough is good enough and if I want better then I should refresh the Navigator myself. I'm not dumb -- I'll know why it didn't take me to the mark. In other words, just keep the old objects and line numbers in the Navigator until I refresh manually. Do your other parsing as usual behind the scenes.

    Yes, perhaps this shouldn't be the default behavior, but I would opt for it given the alternative of not being able to jump out of an edit real quick to see how I did something somewhere else. Currently, I add dummy code to finish the edit just to use the Navigator again or I go looking for that other code the hard way. Both of which slow me down.

    One more note about the Navigator: I notice the performance difference while typing with it on versus with it off so it is clearly affecting something. Anything that causes unnecessary screen drawing seems to be a big problem for editor performance from what I observe. Redrawing the Navigator is one of those situations.

    2 years ago
    0 Agreed
    0 Disagreed
  3. Moderator

    Well, parsing is a background process, but navigator population is not. It is relatively quick, but possibly not fast enough to allow for fluid typing. I'll take a peek at this and see if something can be done. One solution would be to thread the population of the navigator and synchronize its actions with the main Toad thread. I don't know if this will eliminate delays entirely, but it should go a long way.

    Keeping stale items in the navigator is not possible at this time. I'll ponder this and see if there's something that can be done, but my first thought is that it will require maintaining 2 lists of parser results. One to populate the navigator with and one to use internally. The internal list would be the most up to date list and the list that is populated via background parsing. The navigator list would only be used to show those items and would maintain a stale list until it could be refreshed from the internal list with minimal obstruction to what you're doing. For large text there may be a noticeable increase in memory consumption with such an approach.

    2 years ago
    0 Agreed
    0 Disagreed
  4. matthew_jernigan Idea Submitter

    Cool. I can't ask for anything more than that. I guess I could say that I like a smooth editor just like a writer likes a well-oiled typewriter.

    I guess that controlling the sync delay might also be a possibility but changing it from .5 seconds to several seconds might be just plain weird if the navigator were to refresh while I was about to click something. I can think of a "best guess" solution as well but that also has its pros and cons.

    Thank you for thinking about this and entertaining my comments.

    2 years ago
    0 Agreed
    0 Disagreed
  5. matthew_jernigan Idea Submitter

    Okay, there is one more thing I should probably note. Before I turned off the new "Check Rules as you type" feature, editor performance was so poor that some keystrokes were simply being lost. I could do things like hit enter and then press and hold the tab key and I might get a carriage return but I would get no tabs. Perhaps already fixed in 11.1 but I thought I would add it to this thread anyhow.

    2 years ago
    0 Agreed
    0 Disagreed
  6. Moderator

    > Before I turned off the new "Check Rules as you type" feature, editor performance was so poor that some keystrokes were simply being lost.

    This is one area in particular that I have been focusing heavily on for Toad 11.1. I didn't bring it up before because I wasn't sure that you were using it, but I'll outline some of the changes. In Toad 11.0 parsing and check rules as you type were both handled in background threads. Each was performed in its own thread and there was much duplication of work. For Toad 11.1 both are combined in a single thread, eliminating duplicate code and storage. I'm also using our parser in a new way that allows me to bypass costly processing of large XML internally. In addition to general memory leak fixes I've been able to reduce the amount of memory used by the rules processing. There is still work to be done here, but an initial test using my 20,000+ line package uses ~170 MB memory whereas the same used 500+ MB memory in Toad 11.0. It's also processing in a fraction of the time and in a single thread. All of these will improve the overall experience. Syntax highlighting and navigator population are likely the only two bottlenecks now. There's not much I can do about syntax highlighting, but navigator population perhaps can be improved.

    2 years ago
    0 Agreed
    0 Disagreed
  7. matthew_jernigan Idea Submitter

    Excellent! Obviously you are well ahead of me. I liked the check rules feature so it is good to hear I may be able to turn it on in 11.1. Syntax highlighting... yeah, can't live without it but I may tweak it more. Another thing I turned off recently was code folding. Not sure if it made anything noticeably faster but I didn't use it enough to leave it on.

    2 years ago
    0 Agreed
    0 Disagreed
  8. matthew_jernigan Idea Submitter

    I should note that I've been happy with editor performance lately in 11.0 even with the Navigator turned on. Turning off the code folding along with the other features I already turned off must have made the difference. Or, perhaps, the memory leaks cleared up after restarting with these features off.

    Anyhow, I would still love to see a Navigator that only refreshes on demand and uses "optimistic" navigating. Losing Navigator navigation while entering code is still aarg.

    2 years ago
    0 Agreed
    0 Disagreed

Events

  1. The idea was posted
    2 years ago