Fun with an SSD

[mrothman]

My company just upgraded my machine and I have a honkin' big SSD drive (about 400GB available).  The obvious use would be for the files in the projects I'm editing, but because we do a lot of our builds distributed, that's not practical most of the time. I use SlickEdit on Linux and I'm perfectly happy, but I thought I'd throw out there - are there other SlickEdit uses for that SSD that might help performance or let me do things I'm not doing? I already put the spill directory and the config directory there.  One thought I had is our products are gargantuan and I've tended to tag only the parts of the tree that I actually edit or depend on. And I have to guess at that. So every once in a while, I try to go to a tag that isn't there.  I could set the tagging to going one night before I go home and get everything, but I'd have to allocate a gargantuan tag cache (I don't know how much, but it would be in the gigabytes).  Since the tag file is in config directly, I'm already storing that there.  Is there some way I could clue SlickEdit into the fact that it's an SSD and reduce or eliminate my tagging cache?

Or anything else...

As always, kudos to everyone for a great product - been using for decades now...

[Tim Kemp]

Or anything else...

If you don't know what to do with it, you could send it to me.

_{(It never hurts to ask.)}

[mrothman]

Hah! I'll keep that in mind if I'm still struggling in a while.

[Clark]

I'd recommend using that SSD for tagging. Increase the size of the tag file cache to about as large as it will go if you need to (Options>Applcation Options>Virtual Memory>Tag file cache size(KB). Tag files are stored in the same place as the workspace file by default. If your source files are on an SSD, that will help speed up large multi-file tagging operations.

[Dennis]

You can change the workspace tag file directory (Projects > Workspace Properties... > Tag Files Directory...), that way you can keep your workspace files where you want them and redirect the tag files to the SSD.

Increasing the tag file cache can improve performance, but it is unrelated to whether the tag files are on an SSD or not, in fact, one could argue that super sizing the tag file cache is less important when you have the tag files on an SSD, and especially not as important if you create a memory disk for your tag files.

[mrothman]

Thank you Clark and Dennis. Clark, as I say, I can't easily put the actual source files on the SSD, although I'm going to keep pushing on our source control folks here about improving that workflow.  Dennis, when I follow the menu sequence you suggest I get a dialog with the names of my projects in the workspace.  No sign of a place to change tag file locations. When I select one of the projects and click on its properties, I just get the usual project properties with all its tabs, but I still don't see a place to change the location of the tag files.  I can add additional tag files through the tag file dialog (Tools, Tag files), but that's not quite the same thing as changing the target when I add new sources.  I'm still on SlickEdit 2013, if that makes a difference.

However, it's not an issue at the moment, because I had moved my workspace and project files to the SSD anyway, so it is putting the tag files on the SSD also.

[Dennis]

The workspace Tag Files Directory option was introduced in SlickEdit 2014.

[mrothman]

Ah ha.  I've been meaning to upgrade... you shouldn't have made the older versions so satisfying.
Actually, the real problem which I face when upgrading is that I occasionally modify the shipping macro files and then when I get a new version I have to merge my changes with SlickEdit's, which isn't easy since you folks often make substantial improvements (and therefore changes) to the pre-existing .e files.  So knock off with the improvements! 

Example, I recently made some edits to get around the following interesting problem: our shop has shifted towards clang-format for beautifying.  It was easy to write a macro that would exercise clang-format on a selection, using filter_selection.  BUT... the workflow of filter_selection re-beautifies after filtering (makes sense).  But of course in this case that simply undoes the clang-formatting.  (Yes, I could painstakingly create a SlickEdit beautifier file that mimics what our clang formatting does, but I guarantee that if I do that, the owner of the clang format file will change it the next day).  So anyway, I had to change a local variable in beautifier.e to be global so I could suppress that behavior.

When I upgrade, I have to find all the little things like that and see whether you folks have provided a better solution, or if not where the heck has the relevant code moved and does it still have the same names, etc.  This is clearly just a first-world problem and I have no complaints, it just slows down my upgrading cycle until things are slack at work.