Trace File Browser blocking

Does TFB need to block all things Toad when loading filenames and retrieving/parsing files?

Yes, but it loads pretty quickly.

Edit: Oh "Need to". I guess you have a file that is not loading quickly.

I could maybe thread it in the next version. But for now, this is how it works.

Just some numbers:

In my main prod db the "Load Files" populates in ~75 seconds.
With connection pooling and web app multi-page voodoo, with I get stuff in several trace files and often have to retrieve and parse multiples at the same time. Ones of several meg in size can hog my Toad for several minutes.

Oh, so you are talking about the dialog where you select the trace files, not the actual fetching/loading of the trace files once you've selected?


If so, and there are lots (tens of thousands) of trace files in the directory that you are looking in, you can speed it up by purging old trace files from the server. It's that Java code that is collecting all of the trace file names that is running slowly.

If you are talking about the actual loading of trace files after you click OK in this dialog, and you are watching them load 1000 lines at a time, which version of Toad are you on? In version 15.0, I added some code that instead of loading the file line by line this way, it compresses the file on the server, transferrs it as a BLOB, then decompresses the file on the client side. In 15.1, I learned that doesn't work for everyone, so I added more code such that If compress/transfer/decompress process fails, then we fall back to the line-by-line technique. So if you are on 15.1 and seeing the line-by-line, then maybe we can figure out why the compress/transfer/decompress technique is failing and fix that. It's a LOT faster.

I'm talking both. The Load Files is proportional to the # of files and I don't mind the wait, just the loss of other Toad windows. Some places I can purge, but many I cannot. The retrieval and parsing is much more of a drag though on a typical look though. I usually have a second Toad open just to service the trace file processing when I get deep into things.

I added to my reply while you were typing. See my last paragraph above.

This one is still 14.2. Great ammo for nearly 2 month old environment upgrade ticket. I'll see if I can get it upgraded soon since I'm helping with something critical now.

There is a full change log for 15.1 here, and there is a link to 15.0 at the bottom of the page.

16.0 is going to come out next month, so if it will be an ordeal to update, you might want to wait for that version.

I played my cards well with that one and 15.1 magically appeared this morning. One 20.7MB trace was 6:24 processing time with 30 sec retrieval in 14.2 and the same file was 4:31 processing in15.1. The retrieval in 15.1 was faster than my fingers on the clock. I usually trace my stuff with binds =>true so much of the processing bloat is probably in that extra content.

1 Like

Yeah the compress/transfer/decompress technique is so much better than the old method. It almost makes you wonder if it worked right.

There are a couple of bugs that you will want to watch out for in 15.1:

  1. SB-Synonyms - don't set it to PUBLIC or anything that will load more than 500 of them, or you'll get an "out of memory" error and Toad will crash.
  2. SQL Recall not opening. Details and workaround here

Both are fixed in the current beta, which I recommend getting. The beta is nearly finalized at this point.