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

Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
SlickEdit 14 is not ready for prime time
« 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>

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SlickEdit 14 is not ready for prime time
« Reply #1 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.

Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
Re: SlickEdit 14 is not ready for prime time
« Reply #2 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.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SlickEdit 14 is not ready for prime time
« Reply #3 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?
« Last Edit: April 08, 2009, 02:43:21 am by chrisant »

asipe

  • Senior Community Member
  • Posts: 113
  • Hero Points: 4
Re: SlickEdit 14 is not ready for prime time
« Reply #4 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
« Last Edit: April 08, 2009, 12:48:20 pm by asipe »

jim

  • Community Member
  • Posts: 30
  • Hero Points: 1
Re: SlickEdit 14 is not ready for prime time
« Reply #5 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
« Last Edit: April 08, 2009, 04:55:27 pm by jim »

sdonepudi

  • Community Member
  • Posts: 23
  • Hero Points: 0
Re: SlickEdit 14 is not ready for prime time
« Reply #6 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.

imtribble

  • Community Member
  • Posts: 24
  • Hero Points: 3
Re: SlickEdit 14 is not ready for prime time
« Reply #7 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.

skywise

  • Senior Community Member
  • Posts: 331
  • Hero Points: 10
Re: SlickEdit 14 is not ready for prime time
« Reply #8 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.

imtribble

  • Community Member
  • Posts: 24
  • Hero Points: 3
Re: SlickEdit 14 is not ready for prime time
« Reply #9 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.

schugh

  • Community Member
  • Posts: 30
  • Hero Points: 0
Re: SlickEdit 14 is not ready for prime time
« Reply #10 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

Dan112123

  • Community Member
  • Posts: 44
  • Hero Points: 2
Re: SlickEdit 14 is not ready for prime time
« Reply #11 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)

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Re: SlickEdit 14 is not ready for prime time
« Reply #12 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.

buggyfunbunny

  • Senior Community Member
  • Posts: 233
  • Hero Points: 4
Re: SlickEdit 14 is not ready for prime time
« Reply #13 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

Clark

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 5441
  • Hero Points: 444
Re: SlickEdit 14 is not ready for prime time
« Reply #14 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.