Editor - resource usage/efficiency poll

I apologize for the long email, but this is a poll of sorts.

I tried to do quite a bit of work to polish some of the GUI updates and
underlying code for the 10.6 release while adding some features that have been
requested. One area that I wasn’t able to spend as much time on until now
is the overall performance and resource usage of the Editor in particular when
many tabs are opened. The Editor is a pig with respect to the amount of
underlying components created. More and more is always asked of it, other teams
at Quest interact with Toad and want integration points, users request features
that exist in Visual Studio and Eclipse, etc. There is only so much more than
can be squeezed into it before something drastic has to change.

Several years ago when we went to a unified Editor there was much discussion
regarding keeping SQL and PL/SQL workflow separated. Users were familiar with
the SQL Editor and Procedure Editor as separate entities and much of that
familiarity has been forced onto the current Editor. In particular I am
referring to the various tab styles and desktops. The current method, used in
all versions since the unified Editor was introduced, is to have each tab
maintain its own desktop layout. This means that every docked panel that you see
is duplicated across each Editor tab. Some docked panels need to be synched
across all editor tabs, others do not. This requires much work internally to
keep tabs synched correctly and the resource usage is almost out of hand when
working with many tabs.

A method that I’ve been playing with over the past week or so is to have a
single desktop layout. All docked panels are created once for an Editor instance
and all Editor tabs share that space. This is far more efficient. Memory usage
when 50+ tabs are opened is low. Creating new tabs and loading files/objects is
speedy. It’s much easier to handle the few docked panels that should not
by synched across all tabs than it is to handle the synching currently used.
From a design perspective this makes much more sense and the performance is
incomparable between my test build and the GA/beta builds. If you are still
reading, you’ll be saddened to hear that there is a catch. If we are to
remain in this SQL vs. PL/SQL mindset then switching the active Editor tab is
slow. In this model the desktop layout needs to be discarded and reloaded on
each tab change. We aren’t talking significant delays, but easily a full
second or two which feels sluggish and unacceptable to me at least. My limited
experience with other IDEs tells me that Toad is not following the crowd in this
area. Delphi gives you one desktop layout. You can create more and change them
at will, but that change applies to every file opened without exception. If Toad
can evolve to follow this common design then the Editor can be remarkably fast
and efficient for the release after 10.6.

So, what are your thoughts? What is most important to you? I see 3 options.

High resource usage is OK as long as tab navigation is fairly quick. Working
with many tabs may use more memory and GDI resources that my machine can
provide.
High resource usage is unacceptable, but SQL and PL/SQL tabs/desktops are
very important to me and the tab change delay is OK.
High resource usage and tab change delays are both unacceptable and to gain
the maximum speed with the least amount of resource usage I’m willing
to go to a single desktop layout that affects all Editor tabs.

I have not yet explored other docking components to compare layout changing
speed which is another possibility, but the current component set provides
pinning and more complicated dock layouts so a new component set would need to
provide the same. I haven’t seen anything yet that comes close to
providing what ours currently does.

Thanks,

Michael

As an advocate for a “Toad Lite” product for years, my vote is for
option 3.

Best regards,
Mike

Michael S. Zarzycki, MTS | Manager of Engineering IT | Sensata Technologies,
Inc. | voice: 508-236-1015 | fax: 508-236-3701 | www.sensata.com | The World
Depends on Sensors and Controls

Correct. I should’ve mentioned that, but yes the desktop load can be
bypassed in that case.

Michael

In that case, my vote is go for it. I can open one editor for sql and one for
pl/ sql if I want to avoid the delays.

Before I answer I have to know, if I was to vote for a single desktop layout,
would I still be able to have separate grids for each tab so I can easily
compare the results of various queries by switching back and forth between the
tabs?

I’m okay with a single layout and could either do as John mentioned, and
just open a different editor for each kind of work I’m doing, or just not
worry about the tabs I don’t see. Most of the time, I’m either doing
SQL or doing PL/SQL, so having to do that in separate editors is fine with me. .
.

Yes, the only noticeable change would be that the position, visibility, size and
other non-data attributes of a docked panel would be shared across all tabs.
Each active Editor tab would have its own grid as that control can’t be
shared. The current model shares data on certain tabs like breakpoints, watches,
call stack, profiler, script output and dbms output(?). All of this behavior
will be the same in the new.

The new model will show results only relevant to the active Editor tab on the
following docked panels. Grid, Navigator, Auto Trace, Messages, and Explain
Plan. All other panels will share the data in addition to the controls
themselves.

So, in short you should see no difference other than the same dock layout for
each Editor tab.

“So, in short you should see no difference other than the same dock layout for
each Editor tab.”

For instance, if I had raised the splitter to stretch the dbms_output window to
be very tall on one tab but small on another tab this would go away under the
proposed
new model? Stretching/shrinking one stretches/shrinking them all? Is that what
you mean?

Michael Staszewski
Sent by: toad@yahoogroups.com

2010/09/01 13:32

Please respond to
toad@yahoogroups.com

To

"toadbeta@yahoogroups.com" , “TOAD GA List
(toad@yahoogroups.com)”

cc

Subject

[toad] RE: Editor - resource usage/efficiency poll

Yes, the only noticeable change would be that the position, visibility, size and
other non-data attributes of a docked panel would be shared across all tabs.
Each active Editor tab would have its own grid as that control can’t be
shared. The current model shares data on certain tabs like breakpoints, watches,
call stack, profiler, script output and dbms output(?). All of this behavior
will be the same in the new.

The new model will show results only relevant to the active Editor tab on the
following docked panels. Grid, Navigator, Auto Trace, Messages, and Explain
Plan. All other panels will share the data in addition to the controls
themselves.

So, in short you should see no difference other than the same dock layout for
each Editor tab.
att1.dat (43 Bytes)

Yes, option #3 would eliminate that. Option #2 would retain that, but changing
the active Editor tab would be slower.

I could live with that. I vote for #3. . .

can I suggest option 2.5?

rather than let each component control it’s own set of attributes like
size/position/visibility can those be maintained independently at the editor
level?

Each editor would maintain a collection of attributes per child tab, when you
switch tab you lookup the attributes for that tab and adjust the existing/shared
component to that tab’s specification? That doesn’t seem like it should take
much memory or time but maybe I’m deluding myself.

Michael Staszewski
Sent by: toad@yahoogroups.com

2010/09/01 13:39

Please respond to
toad@yahoogroups.com

To

"toadbeta@yahoogroups.com" , "toad@yahoogroups.com"

cc

Subject

RE: [toadbeta] Re: [toad] RE: Editor - resource usage/efficiency poll

Yes, option #3 would eliminate that. Option #2 would retain that, but changing
the active Editor tab would be slower.
att1.dat (43 Bytes)

Option 2.5 = option 2.

When we reapply those attributes on active tab change there is a 1-2 second
delay while the docking manager applies the layout settings. It’s not that
much resource usage, but the delay is just long enough to make you say hmmm.

Two would be a tremendous hardship over here. I frequently have 10 to 17 tabs
open for our various facilities. I’ll vote for three.

Darlene R. Ulmet

Financial Analyst II

Revenue Cycle

Strategic Financial Planning and Analysis

Baylor Health Care System

Phone: (214) 820-1936

Fax: (214)820-8515

Email: Darlene.Ulmet@BaylorHealth.edu

“It is never too late to become what you might have been.”

George Eliott (Mary Ann “Marian” Evans Lewes Cross)

(1819-1880)

Mike already knows this, but just thought I’d make it public. I’ve
been playing around with a dev build and I’m a huge fan of #3. I
don’t like seeing the flickering and resizing of sub-tabs. I like having
all available sub-tabs open and available in case I need them. I like a fast
response time when I click on tabs. I found it irritating when I pasted pl/sql
into an Editor tab, compile, and go to debug, only not to find my breakpoints
and watches sub-tabs because I was in a “SQL” style tab.

I guess my problem with a single desktop is I have different layouts for
SQL vs PL/SQL

For PL/SQL I have the Navigator on the left with no bottom tabs grid,
dbms_output and so on.

For SQL The navigator is not to important for me so it is on the right
but I have most tabs showing on the bottom, grid dbms, script output and
so on.

I guess I could adjust to the navigator being on the same side but for
PL/SQL I don't need the tabs at the bottom but for SQL I do.

Ed
[TeamT]

On 9/1/2010 1:32 PM, Michael Staszewski wrote:

Yes, the only noticeable change would be that the position, visibility,
size and other non-data attributes of a docked panel would be shared
across all tabs. Each active Editor tab would have its own grid as that
control can’t be shared. The current model shares data on certain tabs
like breakpoints, watches, call stack, profiler, script output and dbms
output(?). All of this behavior will be the same in the new.

The new model will show results only relevant to the active Editor tab
on the following docked panels. Grid, Navigator, Auto Trace, Messages,
and Explain Plan. All other panels will share the data in addition to
the controls themselves.

So, in short you should see no difference other than the same dock
layout for each Editor tab.

well shoot,

if it really takes that long then I guess I probably vote for #3 as well.
I don’t think I resize stuff that often that it’d be an irritant if the rest of
my editting experience is faster/smoother

Michael Staszewski
Sent by: toadbeta@yahoogroups.com

2010/09/01 13:55

Please respond to
toadbeta@yahoogroups.com

To

"toadbeta@yahoogroups.com" , "toad@yahoogroups.com"

cc

Subject

RE: [toadbeta] Re: [toad] RE: Editor - resource usage/efficiency poll

Option 2.5 = option 2.

When we reapply those attributes on active tab change there is a 1-2 second
delay while the docking manager applies the layout settings. It’s not that
much resource usage, but the delay is just long enough to make you say hmmm.

Is it acceptable to have 2 component sets - for SQL and PL/SQL editors -
and keep one desktop layout for SQL style editors and one for PL/SQL
style editors?

Looks like you only wanted to separate those two styles to me…

This sounds like a good compromise to me - when I’m using PL/SQL, I want as much
vertical space as I can get & I’d ideally want a really stripped-down menu
structure there to give me even more space.

However, when I’m using SQL, I’m not usually that bothered about vertical space,
but I do want the data grid, DBMS output & script output tabs, for example.

How about a Microsoft ribbon-like approach - or is that too slow using Delphi?

Ian

I am a DBA and rarely write PL/SQL, so #3 is best for me. If not #3, then I want
Toad to use as little of my resources as possible, so #2 is my 2nd choice.

Rik Cosgrave

Ribbons are irrelevant to this discussion. Sorry for the short reply, but I’m
typing on my phone and want to prevent thread derailment.

On Sep 2, 2010, at 8:00 AM, “Taylor, Ian” wrote:

This sounds like a good compromise to me - when I'm using PL/SQL, I want as
much vertical space as I can get & I'd ideally want a really stripped-down
menu structure there to give me even more space.

However, when I’m using SQL, I’m not usually that bothered about vertical
space, but I do want the data grid, DBMS output & script output tabs, for
example.

How about a Microsoft ribbon-like approach - or is that too slow using
Delphi?

Ian