Author Topic: SlickEdit 14 is not ready for prime time  (Read 22716 times)

mitcheljh

  • Community Member
  • Posts: 52
  • Hero Points: 2
Re: SlickEdit 14 is not ready for prime time
« Reply #15 on: April 08, 2009, 08:12:48 PM »
Quote
FWIW, after SE13 was released, I saw lots and lots of posts in the forums slamming VS for not having symbol coloring, and demanding for it to be implemented immediately.    It is true that you can't please everything all the time.

We have to admit this is correct.  I was one of the ones who anxiously waited for symbol coloring, and I remember seeing many requests for the same.

I agree that the feature is a little slow, but I'm willing to give it some time to see what happens, since...
1) The symbol coloring is much more feature rich than symbol coloring in other editors (which may be part of the reason for it being a little slow)
2) It just came out, so may not be optimized fully yet.  I'm hoping future updates will find this feature optimized more, so it becomes much more usable.

Incidentally, I recently changed my SE Option Tools->Options->Editing->Number of lines to color above and below the current page
to 0 (zero), and it had a big effect on speeding up my scrolling up and down the document.  (No more pauses!)  You might want to give this a try.
« Last Edit: April 08, 2009, 08:40:36 PM by mitcheljh »

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: SlickEdit 14 is not ready for prime time
« Reply #16 on: April 08, 2009, 10:10:43 PM »
@Dan112123, can you provide some more detail on your performance issues? I have a dual-core 2.19 GHz machine with 2GB of RAM, and performance is always snappy. I don't work in C#, but I do test some sample applications and have not seen the kind of lag you are describing. Have you tried SlickEdit 2009 with Symbol Coloring off and don't get the same freezes?

@sdonepudi, does this hang happen every time you hit Page Up or Page Down? To be very clear, is the whole application frozen or is it just that the symbol coloring takes 2-3 seconds to draw? There is a timeout set on the Symbol Coloring to prevent long pauses.

We haven't found any reproducible cases of symbol coloring hanging SlickEdit for more than a moment. We're very interested in finding one so we can see what's going on. But we need to be sure that people are not interpretting the lag in drawing the colors as a hang. We've tried very hard to make sure that the drawing doesn't get in the way of coding, which actually contributes to the lag in drawing. There is a default lag of 500 milliseconds before we start drawing. See Tools > Options > Editing > Context Tagging and scroll to the bottom for "Symbol coloring performance" options.

The number of rules will not affect the performance of Symbol Coloring until you have a lot of rules. The time is spent on symbol analysis to determine what kind of symbol it is. Applying the rule once we know the kind of symbol is the easy part.

@asipe, can you provide more information about your experience with XML, maybe  in a different thread? I edit XML documents frequently and never see any kind of lag when saving. Are your files stored on a network drive? We have an option to validate a file when it is opened, which could cause some lags at that point. But I don't see one for validating on save.

Regarding feature choices: unfortunately, there isn't time to do everything. We chose Symbol Coloring because of the demand from users, and we believe it provides very important information to help with coding. Seeing undefined symbols can save unecessary compile cycles that are caused by simple typos. Highlighting global variable can be a big help when writing multi-threaded code.

The enhancements to our embedded language support is definitely on the radar, but this is not as trivial as you might think. D language support was trivial given its similarity to C/C++. 

Thanks for the feedback!


sdonepudi

  • Community Member
  • Posts: 23
  • Hero Points: 0
Re: SlickEdit 14 is not ready for prime time
« Reply #17 on: April 09, 2009, 01:50:09 AM »
Scott thanks for looking at these issues. Whenever ever I press Page up or down the Slickedit kind of freezes for 2 to 3 seconds and displays new page. After that Slickedit starts changing symbol colors in the new page.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: SlickEdit 14 is not ready for prime time
« Reply #18 on: April 09, 2009, 02:34:25 PM »
@sdonepudi: I still need an answer to what you mean by "freezes". During that 2-3 seconds, are you saying that SlickEdit does not respond to keyboard input, or are you saying that it takes that long for the colors to be drawn--these are two very distinct issues. If you mean that SlickEdit doesn't respond to keyboard input, do you get the same behavior with Symbol Coloring off (set to "none")? Looking at my test instance, which uses Visual Studio 2005, the C# tag file is 131,176 KB. That's considerably larger than the default tag file cache size. So, you want to increase that whether these pauses only happen when Symbol Coloring is not set to "none" or not. Select Tools > Options > Editing > Context Tagging and change the value for "Maximum tag fiel cache size" to "200,000". That should give you plenty of overhead for a good sized workspace tag file too. Or pick a number based on the sum of your C# tag file size and your workspace tag file size. Check the Performance Tuning section in the Introduction of the User Guide for more detailed instructions.

@jim: even a 15Kb C# file can use a collossal library. .NET has to be the all-time framework leader, providing more APIs for more things than any other environment. So, we need to have adequate space to work with the tags for those libraries. We already have some users complaining about the amount of memory we use, so we try to pick defaults that aren't excessive for the average user.

Back to sdonepudi: if your pauses are occuring only with Symbol Coloring on (not set to "none"). Then we can try to tune that a bit. On the Editing > Context Tagging options page, change the value for "Timeout after (ms)" in the "Symbol coloring performance" group. The default is 1 second, 1000 milliseconds. Change that to 500. Does that fix/reduce the pauses? Change it to 250. What effect did that have?

For anyone who wants to reduce the lag before the colors are rendered, change "Update after (ms) idle". There is some contention for resources when Symbol Coloring is doing the anlaysis, so be careful setting that too low particularly with the default value for the timeout.

@asipe: actually, very few other editors offer coloring based on symbol properties, like scope and whether it is defined or not. I have no doubts that some may be more performant or require less tweaking. If, like ReSharper, we knew that all we were going to deal with was .NET, then we could pick different defaults. However, the defaults needed for .NET would not be optimum for the typical C/C++ project. ReSharper also only supports C# and VB.NET (I believe) and only has to run on one platform: Windows. I certainly think we can improve our Symbol Coloring implementation, but you make it sound like we botched a simple feature that everyone else provides, which is overstating the issue.  ;)

sdonepudi

  • Community Member
  • Posts: 23
  • Hero Points: 0
Re: SlickEdit 14 is not ready for prime time
« Reply #19 on: April 09, 2009, 02:41:27 PM »
Scott when I press Page UP or Down with symbol coloring on it takes 2 to 3 seconds to display new page. During this times it accepts new key strokes. This problem does not happen without Symbol Coloring off.

schugh

  • Community Member
  • Posts: 30
  • Hero Points: 0
Re: SlickEdit 14 is not ready for prime time
« Reply #20 on: April 09, 2009, 04:11:51 PM »
FWIW, after SE13 was released, I saw lots and lots of posts in the forums slamming VS for not having symbol coloring, and demanding for it to be implemented immediately.  :P  It is true that you can't please everything all the time.

Is that right? I didn't know that was the case. I guess in that case then Slickedit did right by adding this feature if there was so much demand for it.
It just doesn't add much for me personally.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SlickEdit 14 is not ready for prime time
« Reply #21 on: April 09, 2009, 05:31:11 PM »
Scott when I press Page UP or Down with symbol coloring on it takes 2 to 3 seconds to display new page. During this times it accepts new key strokes. This problem does not happen without Symbol Coloring off.

It sounds like you're saying this:
- You press Page Up or Down.
- The file immediately scrolls up or down appropriately.
- The editor continues to respond to keys.
- The symbol coloring doesn't show up for 2 to 3 seconds.

Is that what you're saying?
Just trying to get a crisp understanding of what you're seeing, because the subtle details make a big difference in terms of diagnosing what setting(s) to tweak to improve the behavior.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: SlickEdit 14 is not ready for prime time
« Reply #22 on: April 09, 2009, 06:53:39 PM »
@sdonepudi: Sounds like we're getting closer to the definition of "freezes". When you say, "...it takes 2 to 3 seconds to display new page", I would take that to mean that no text is drawn at all, that you just see a blank background. Is that correct? Or, is it as chrisant asks that it just takes that long for the additional symbol colors to render?

If we're just talking about the delay before the Symbol Colors are rendered, try reducing the value for "Update after (ms) idle" as I posted previously. You didn't post your machine specs like most of us in this thread. What CPU and how much memory are you using?  With the default settings, 2 seconds may be reasonable since it won't even start the analysis for 0.5 seconds after your last input. I could see 3 seconds if there was some paging needed for the tag file or you are on a slower machine. What language are you using?

Which Color Scheme and which Symbol Coloring Scheme are you using? For example, I'm using Chalkboard with "All symbols - Dark background".
« Last Edit: April 09, 2009, 07:29:59 PM by ScottW, VP of Dev »

Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
Re: SlickEdit 14 is not ready for prime time
« Reply #23 on: April 09, 2009, 06:56:48 PM »
Is there anyone who could help answer some question we have with the APIs? This would help us when we pick this back up.

Clark thank you for your response. Please send all your questions to me, I should be able to answer most of them or someone who will.

Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
Re: SlickEdit 14 is not ready for prime time
« Reply #24 on: April 09, 2009, 07:03:56 PM »
@Dan112123, can you provide some more detail on your performance issues? I have a dual-core 2.19 GHz machine with 2GB of RAM, and performance is always snappy. I don't work in C#, but I do test some sample applications and have not seen the kind of lag you are describing. Have you tried SlickEdit 2009 with Symbol Coloring off and don't get the same freezes?

I'm sorry Scott, I don't have the time to debug SE right now, I'm going to wait and give it a try in 5-6 month.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Re: SlickEdit 14 is not ready for prime time
« Reply #25 on: April 09, 2009, 07:26:10 PM »
@Dan112123, I understand how you feel. Check back after our summer release and let us know if you're still having those issues.

asipe

  • Senior Community Member
  • Posts: 113
  • Hero Points: 4
Re: SlickEdit 14 is not ready for prime time
« Reply #26 on: April 10, 2009, 02:05:07 PM »
Quote
@asipe: actually, very few other editors offer coloring based on symbol properties, like scope and whether it is defined or not. I have no doubts that some may be more performant or require less tweaking. If, like ReSharper, we knew that all we were going to deal with was .NET, then we could pick different defaults. However, the defaults needed for .NET would not be optimum for the typical C/C++ project. ReSharper also only supports C# and VB.NET (I believe) and only has to run on one platform: Windows. I certainly think we can improve our Symbol Coloring implementation, but you make it sound like we botched a simple feature that everyone else provides, which is overstating the issue.

I can agree with your points about resharper and only dealing with c# and windows, etc...  But that doesn't really help with the problem, does it?   Basically you are saying that they can provide better performance because they are serving a narrow market.   OK, and this means what?   Heck, I'm not even focused on the latest version, I've moved back to the previous version and still have complaints.

The fundamental problem is that VSE is so much slower that over the last 2 months I have stopped using it for any C# work.  The other tool combo is just so much faster and gives me 99% of the features that I need.   Sure, I can make VSE faster by turning off all its features but then what is the point?

The problems that VSE has with C# are fairly well documented in other threads but to summarize:

* tagging problems (even worse with symbol coloring)
* slow response time when jumping between references
* in ability to tag different frameworks for different projects
* slow slow slow integration with msdn help and again the inability to configure this on a per project basis for different frameworks
* constant manual retagging
* core features like surround and formatting don't work reliably, not to mention weird behavior when handling anonymous methods, delegates, templates, linq  (format on paste, comment/uncomment, etc...)
* the inability of vse to handle multiple embedded languages inside files (aspx/js/embedded c#/etc...)
* poor xml performance overall
* always behind the features of the core frameworks

I understand that none of these are simple issues and I'm not saying they are simple fixes, but they are problems that the alternatives do not have.   

Interestingly enough I can point to many of the same problems (and even more) in the ruby language support.   That said, I pretty much stopped bringing these issues to the forums after hearing that ruby (as a language/spec) is moving far to fast for VSE to keep up (sigh).  This coupled with some other recent support issues is a trend that I find disturbing.

I don't write an editor for a living.  I don't want to have to spend time optimizing my editor for basic language support.   I want to turn on my editor and have the features it says it supports in the languages it supports work with reasonable size projects in a speedy manner.  Is that odd?   

-andy





Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
Re: SlickEdit 14 is not ready for prime time
« Reply #27 on: July 23, 2009, 03:58:20 PM »
I have not been using SlickEdit since April and switched entirely to vim and VisualStudio. Did anything improve while I was not using it? It is worth trying it out again?

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SlickEdit 14 is not ready for prime time
« Reply #28 on: July 23, 2009, 08:11:05 PM »
I admit to not having time available to read through the whole topic and evaluate all of the specific concerns, but I'm going to go with "Yes, there have been improvements, and it is worth trying".  Your mileage may vary.