Author Topic: What is SE doing with constants?  (Read 4059 times)

Duhhh

  • Community Member
  • Posts: 36
  • Hero Points: 0
What is SE doing with constants?
« on: April 25, 2008, 09:52:48 am »
I opened a large (3mb) C header file that defines some video images as arrays, like:

u8 video_frame1[] = {0x01, 0x02, 0x03......}

The arrays are 640 x 480, so each line is 3889 characters long. When SE opens the file for the first time, it goes dead for a few minutes before I can edit the file. VS.exe has one CPU completely pegged the whole time.

Is it really trying to look up every constant in the C tag file or something? If I rename the file with a .txt extension, it loads instantly. Is there any way to calm SE without renaming these files?

Graeme

  • Senior Community Member
  • Posts: 1978
  • Hero Points: 226
Re: What is SE doing with constants?
« Reply #1 on: April 25, 2008, 09:10:20 pm »
Quote
Is it really trying to look up every constant in the C tag file or something? If I rename the file with a .txt extension, it loads instantly. Is there any way to calm SE without renaming these files?

Try setting the document mode - "select mode" on the document menu.  It gets remembered across invocations of slickedit.  Maybe try removing it from the tag file  -  I suspect that won't help though.  Maybe also try and disguise the array using #defines so that slick doesn't interpret it as an array  - dunno how you would do that though.  Maybe move the big tables to a separate file of their own that gets #included by the header file.

Graeme

Duhhh

  • Community Member
  • Posts: 36
  • Hero Points: 0
Re: What is SE doing with constants?
« Reply #2 on: May 09, 2008, 03:41:17 am »
By the time I read your reply, the trial expired, so I wasn't able to try what you suggested.  :(

This file in question isn't part of a tag file. I did try disguising the array, but nothing seemed to help, other than if I changed the file extension to .TXT so VS wouldn't even try to parse it. I guess I could do that, and just #include a .txt file (with an explanation so others wouldn't think I was nuts).

I'm back to using SE 10, and it does also choke on this file, but not as badly. The same workaround helps.

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: What is SE doing with constants?
« Reply #3 on: May 09, 2008, 04:54:50 am »
Can you chop the file down to about 200KB or so and post the shrunken file?  That way someone can investigate and come up with a fix.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2209
  • Hero Points: 275
Re: What is SE doing with constants?
« Reply #4 on: May 15, 2008, 02:37:05 pm »
You can go to Tools > Options > Editing > Context Tagging Options, and trim back the following setting"  "Max size of files to tag (KB)"   Try 2048 instead of the default of 4096.  This will prevent SlickEdit from trying to do context tagging on very large source files.  Of course, it will also mean you get no help from the Defs tool window.  Note this setting was also available in v10.0 (and as far back as v4.0).


Sending in a sample file to support would give us an opportunity to profile the performance issue and perhaps speed it up a little bit, but I wouldn't cast any guarrantees, considering that no matter what, we are parsing through 3M of source code, and that is a pretty large amount of parsing.


Duhhh

  • Community Member
  • Posts: 36
  • Hero Points: 0
Re: What is SE doing with constants?
« Reply #5 on: May 16, 2008, 09:08:49 pm »
Well, it happened on my 10.0 system today. I changed the max size to 1MB, and opened a 7MB file. 5 minutes later, I still have an hourglass. VS.exe is sucking up all spare CPU time. Doing what, I don't know.

After vs came back to life, I started to edit the file - I just added another "name_tag" item, and started changing the name. Vs locked up again, and started sucking up CPU time. After another 5 minutes, I killed vs.exe.

I can't see if 13.0 reacts differently, because the trial expired.

The file looks like:

u32 name_tag = 0x01020304;

u8 frame1_data[] = {
0x01, 0x02, 0x03, 0x04, 0x05, 0x06, .... (640 entries per line)
.
.
. (480 lines long)
};

u8 frame2_data[] = {
0x01, 0x02, 0x03, 0x04... (same as frame1_data)
.
.
.
};


That's it. Most frames are 640x480, but some are larger. I usually have at least 3 frames per file.

If it's not context tagging, what is it? Is there any way I tell vs.exe to give me a hint about what it's doing? If I rename the file to .txt, I get no delay.
« Last Edit: May 16, 2008, 09:20:01 pm by Duhhh »

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2209
  • Hero Points: 275
Re: What is SE doing with constants?
« Reply #6 on: May 16, 2008, 10:05:46 pm »
Profiling the example pinpointed the slow area.  This will be fixed in 13.0.1.  Sorry, this is not hot-fixable.  In my test case, performance improved from around 7 seconds to 1/4 second for tagging to update a 4M C++ source file of the form you described.  You should be able to download a new trial when 13.0.1 comes out.  Should you decide to upgrade, I expect you'll find the improved parsing peformance adaquate.

In the meantime, I'd suggest using Graeme's workaround.

jporkka

  • Senior Community Member
  • Posts: 136
  • Hero Points: 6
Re: What is SE doing with constants?
« Reply #7 on: May 19, 2008, 04:58:02 pm »
Along these lines I've found that Slick 13 is quite slow in general with large C++ files.

I was recently trying to work with preprocessor output and found Slick would lock up for long periods.

Take any Windows source file, #include windows.h and other stuff.
Generate preprocessor output with CL /P.
Load the file in slick and ensure it is in C/C++ mode.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2209
  • Hero Points: 275
Re: What is SE doing with constants?
« Reply #8 on: May 22, 2008, 05:02:14 pm »
@jporkka:  After some testing, I did discover a noticable slowness when the Class tool window was active and working with very, very large files.  Of course, nothing is blindingly fast once you are working with a file that is over 2M of dense source code.  I will put the performance improvements for the Class tool window into next patch release.  They are not hot-fixable.

This may or may not be the performance issue that you found.  When reporting performance issues, well, any bug for that matter, it is really helpful to include some notes about what where the cursor was and what you were doing when the issue happened.  I am assuming you are not just talking about the time required to open the file.