SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Topic started by: Dan112123 on April 08, 2009, 12:50:09 am

Title: SlickEdit 14 is not ready for prime time
Post by: Dan112123 on April 08, 2009, 12:50:09 am
<venting>

I'm very disappointed with the quality that you guys put out. It seems that either you do not care about the quality and not test your own product, or you release it just for the sake of releasing just to get it out there and make us all upgrade to the new version.

Let's take symbol coloring for example. It is very slow and hangs SlickEdit for periods of 1-2 minutes when parsing my 15Kb C# file. And that's on a Quad Core 2.5Gz machine with 4Gb of RAM.

Before I got SE14 installed on my system I though Outlook was the champion of Memory hogs out there. SE14 beat that record today by 30%!!!!!. SE14 is now the absolute champion. No other process on my system uses more RAM including SearchIndexer that indexes my 4Gb source code tree.

Bottom line SE14 has been unusable for me if I turn on the new features. I am very disappointed.

</venting>
Title: Re: SlickEdit 14 is not ready for prime time
Post by: chrisant on April 08, 2009, 01:40:54 am
The speed issues with symbol coloring have been discussed at length in the forums.  If you use the Search you can find useful tips, like using a smaller set of coloring rules.

How much memory exactly is SE14 using?
How much memory exactly did SE13 use?

Memory is a resource to be used.  For example, I have SE configured to use 400MB for the symbol cache.  So right off the bat, it's using more RAM than any other application I use aside from World of Warcraft.  But, I use SE more than any other application, including World of Warcraft.  I want it to have as much memory for its needs as possible.  I expect memory to be used responsibly, of course, but if I expected applications to avoid using memory, I'd be denying them the one resource that can most easily help their performance.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: Dan112123 on April 08, 2009, 01:46:08 am
I use a total of 5 rules and I can't use SE, it is unusable and freezes up all the time. Even if I switch away from SE and switch back.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: chrisant on April 08, 2009, 02:27:04 am
I have a dual core 2.6GHz box with 4GB RAM.
I have a night and day different (much better) experience than you are having.
(I even have a 317MB tag file, and a project with ~40,000 files).

I read the Performance Tuning section in the Help, and that helped me tweak various settings to improve performance.
I think the tag file cache is a big help.

Also, do you have any files coming from remote drives?
Title: Re: SlickEdit 14 is not ready for prime time
Post by: asipe on April 08, 2009, 12:37:52 pm
Unfortunately I agree with the original poster.

Quote
The speed issues with symbol coloring have been discussed at length in the forums.  If you use the Search you can find useful tips

This is true, in fact there were pausing issues even before the 1.4 version came out (without symbol coloring).   Even after repeated posts the problems still exist.

* Handling XML files of any size is an exercise in futility.   It takes 20 seconds to save it...   I don't edit xml in SE anymore, way to slow.
* Continually pausing during manipulation of C# files became such a problem that I actually gave up.   No matter what I changed there were still pauses and I constantly have to retag manually just to get mediocre performance.   As said, it is on the forums in multiple posts.   
* Symbol coloring is making it even slower.   I dunno why it is slower and I want to really like the feature but with the current setup things just aren't fast enough.  Considering that this is the major feature I'm disappointed.

I can run the same 7000+ source file project through VS 2008 and resharper and have instant responses (and I do mean instant).  But in SE the pausing is just to much.    I really do like SE better as it has better pure code handling features but it just isn't worth the hassle in its current form :(

Why does SE require all this extra tuning for a feature that, for the most part, other editors are providing without any tuning what so ever?

-andy
Title: Re: SlickEdit 14 is not ready for prime time
Post by: jim on April 08, 2009, 01:30:54 pm
I hate to complain, as I still remember my happiness at discovering an editor that could finally replace my beloved but moribund Codewright, but I also have to agree with the original poster, and just reverted to the previous version of SE, at least until the File Open panel is usable to me again:

   http://community.slickedit.com/index.php?topic=4690.0

Also, while I haven't run into the performance issues with symbol coloring, that's because I spent my first few days with SE gradually turning off all the features designed to help me.  Coloring, code-completion, "smart indent", etc.  I'm am becoming increasingly wary of any feature (in any product) with the word "Smart" in the title.  :-)

It also seems to me that parsing a "15Kb C# on a Quad Core 2.5Gz machine with 4Gb of RAM" should not require searching the forums for tips, using fewer coloring rules, or reading the performance tuning section of the help to get it to work.  Note that this is NOT a criticism of chrisant's attempts to help!  It's just unfortunate that that is what's required.

Honestly, my biggest disappointment in having to downgrade (aside from it being necessary) is that a regex bug had been fixed in this release.  I'd rather see a refactoring release than all these new features that are--for me, at least--just icing on top of the cake that is editing text.

Jim
Title: Re: SlickEdit 14 is not ready for prime time
Post by: sdonepudi on April 08, 2009, 01:58:47 pm
I hate to complain too. I was a codewrite user before but I have switched to Slickedit 2 years back and I loved it. Symbol coloring is a bug disappointment for me. As suggested in other forums I have enabled profile UNKNOWN which is supposed to set Color for only UNKNOWN variables. Still my system freezes for 2 to 3 seconds when I do Page UP or Down. Also changing clors in front of your eyes is also very distracting. That is the reason why I have decided to switch off Sumbol cloring feature.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: imtribble on April 08, 2009, 02:36:00 pm
I'll agree with the slowness of the editor. I love the editor but version 14 is SO slow. I've had to reinstall 2008 to get work done.  :-[

I'm sure it will get better.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: skywise on April 08, 2009, 03:51:53 pm
If you're having Symbol Coloring issues, go to Tools | Options | Appearance | Symbol Coloring and select a scheme of NONE.

You'll still get the original coloring as per Ver 13 but you won't get the enhanced symbol coloring.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: imtribble on April 08, 2009, 04:46:38 pm
If you're having Symbol Coloring issues, go to Tools | Options | Appearance | Symbol Coloring and select a scheme of NONE.

You'll still get the original coloring as per Ver 13 but you won't get the enhanced symbol coloring.

I'll give that a try. Thanks.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: schugh on April 08, 2009, 04:47:28 pm
I agree with the people having the problems. I have turned off symbol coloring.
I will look into (when I have some time) into the tuning options.
However, I have to agree with some posters that I find it silly that I should have to even think about having to tune especially for small projects.

Moreover, I had noticed in version 13, that Slickedit does not tag references in .NET project. I have to manually create and add them to a tag file.
This is still the same in version 14.
I don't understand why Slickedit spends time on symbol-coloring which provides dubious productivity (it's a nice to have feature but not a requirement) to begin with in my opinion and still not provide
something simple such as tagging the references which is an instant improvement.

It is these things and also performance of tagging etc that is increasingly making me disappointed with slickedit.
Sometimes I feel as if slickedit is just not listening to it's customers.

It happens so often that when I type something that requires auto-completion of some sorts I end up having to wait many long seconds for slicedit to come back.
That's just ridiculous. And yes I have tried buffer size options for tagging etc.

Again just my opinions.

-- Sanjay
Title: Re: SlickEdit 14 is not ready for prime time
Post by: Dan112123 on April 08, 2009, 05:18:09 pm

I don't understand why Slickedit spends time on symbol-coloring which provides dubious productivity (it's a nice to have feature but not a requirement) to begin with in my opinion and still not provide
something simple such as tagging the references which is an instant improvement.

-- Sanjay

Exactly Sanjay!!! I would rather see support for CDB/NTSD then coloring. Do SlickEdit people know that to write support for CDB will take 2 months for a person? All you need to do is make calls to DBGHELP.DLL. Heck John Robbins wrote his own debugger in 3 weeks by making calls to DBGHELP.DLL. SlickEdit lost a lot of street credit with this release for me. So much so that I'm looking at other options again. (and here I though SE was "it" for me)
Title: Re: SlickEdit 14 is not ready for prime time
Post by: chrisant on April 08, 2009, 05:32:00 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: buggyfunbunny on April 08, 2009, 06:40:02 pm
With regard to Symbol Coloring, two points. 

First, opening the setup screen is an exercise in visual overload.  There is nothing to give you a much clue what to do next.  Well, except to read through all the Help.  "Don't Make Me Think" is a good book to read.  Coders, as users of programs, are just Plain Dumb Users of your UI. 

Second, I would have thought that Symbol Coloring, to be easily usable, would act as Delta to Coloring.  From what I can see, it doesn't.  One has to build (code, really) a scheme; perhaps one for each language one needs to use.  For the java framework coders that would be:  java, xml, ini, jsp, jsf, xhtml, html, xsd, js, sql, template, and likely more that I have since forgotten.  Or, what could be worse, figure out a single scheme which supports all of these without collisions.

In previous versions of SE, I found, in the java framework world, the need for one, may be two, additional categorizations in Coloring to get sufficient granularity.  There are, after all, only *6* colors, primary and secondary; 12 (max, I can't remember both sets right now) if you differentiate light colors and pigment colors. 

OTOH, instead of Symbol Coloring (as implemented) if SE coders had built either:
1)  support for multiple embedded languages, thus helping <language du jour> web framework coders
2)  full support for 2 additional <language du jour>s (and how did D bubble to the top of the sort, anyway?)
I suspect that the number of happy campers would be higher and the number of grouchy campers lower than what has occurred.

2 pence
Title: Re: SlickEdit 14 is not ready for prime time
Post by: Clark on April 08, 2009, 08:07:47 pm
Exactly Sanjay!!! I would rather see support for CDB/NTSD then coloring. Do SlickEdit people know that to write support for CDB will take 2 months for a person? All you need to do is make calls to DBGHELP.DLL. Heck John Robbins wrote his own debugger in 3 weeks by making calls to DBGHELP.DLL. SlickEdit lost a lot of street credit with this release for me. So much so that I'm looking at other options again. (and here I though SE was "it" for me)

We took a stab at doing a Windbg-like debugger but didn't allocate enough time for it. Debuggers are very popular. V14 has new debuggers for PHP, Python, and Perl. Sorry, we didn't finish a Windbg debugger. Is there anyone who could help answer some question we have with the APIs? This would help us when we pick this back up.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: mitcheljh 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: ScottW, VP of Dev 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!

Title: Re: SlickEdit 14 is not ready for prime time
Post by: sdonepudi 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: ScottW, VP of Dev 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.  ;)
Title: Re: SlickEdit 14 is not ready for prime time
Post by: sdonepudi 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: schugh 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: chrisant 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: ScottW, VP of Dev 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".
Title: Re: SlickEdit 14 is not ready for prime time
Post by: Dan112123 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: Dan112123 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: ScottW, VP of Dev 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.
Title: Re: SlickEdit 14 is not ready for prime time
Post by: asipe 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




Title: Re: SlickEdit 14 is not ready for prime time
Post by: Dan112123 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?
Title: Re: SlickEdit 14 is not ready for prime time
Post by: chrisant 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.