I recently installed TOAD 10.6 and ran into a problem.
I created a test case:
CREATE OR REPLACE PACKAGE testpkg is
procedure proc1;
end testpkg;
/
CREATE OR REPLACE PACKAGE BODY testpkg IS
procedure proc1 is
procedure proc2 is
procedure proc3 is
t_test number;
begin
t_test := t_test + 1;
t_test := t_test + 1;
t_test := t_test + 1;
t_test := t_test + 1;
end proc3;
begin
proc3;
end proc2;
begin
proc2;
end proc1;
END testpkg;
/
Just repeat the " t_test := t_test + 1;" line 200 times and TOAD uses
50% of my cpu for 40 seconds. It looks like TOAD is parsing the code.
If I try to compile my package, it would not compile until it finishes
the parsing. If the package has thousands of lines, it’s hours instead
of 40 seconds.
It looks like it’s related to the fact that there are sub-procedures.
In my test case, if you remove proc2 (and the call to it), it’s OK.
In TOAD 10.5, even with thousands of lines, I can compile within 1 second.
–
Louis Brouillette
Chargé de projet informatique et technologique (DBA)
Université du Québec à Trois-Rivières
Tel: (819) 376-5011 ext. 2435
Email: Louis.Brouillette@uqtr.ca
I will use this opportunity to say a couple things about the parsing in 10.6 and going forward. Let’s ignore your example for a bit as I’ll speak of the ideal situation where there is no bug.
High CPU usage isn’t necessarily a bad thing if it’s non-blocking. The Editor will now parse (in a thread) as you type and only on idle activity. When you stop typing for just a fraction of a second Toad uses as much CPU as it can get to parse as fast as possible. If you start typing while the Editor is parsing it stops and you should notice no ill effects from the parsing or momentary periods of high CPU usage. If the parsing has finished and the navigator tree is populating then there may be a brief period waiting for the tree to finish loading, but even this should be fast in moderately large packages and the timing would need to be just right to experience any delay in this area.
The Editor also smart parses. As you edit text there is a range of text that has been modified. The text before the range is unmodified and that after the range is unmodified. The Editor will only parse the text that has been invalidated by recent modifications. This is pretty efficient.
I think that there is this perception that when an application is pegging a CPU core that there is a problem and I don’t necessarily agree with this if the application responds quickly to your input. Most new CPUs these days have up to 8 cores so we should be taking advantage of that, right? It would be a little overkill to have a quad core (or more) CPU sitting there with nothing using it.
About CPU usage, I do not totally agree with you. I hate it when an application
is too smart and decides what is best. There could be reasons why some of the
cores (I don't have 8!) are left idle. Power consumption? Special
applications that are blocked out? So if an application wants to try to take all
over the resources, then make it into an option to let it get them instead of
deciding to take all possible cores.
Groetjes,
Wim
On Mon, Oct 4, 2010 at 17:15, Michael Staszewski
wrote:
I will use this opportunity to say a couple things about the parsing in 10.6
and going forward. Let's ignore your example for a bit as I'll speak
of the ideal situation where there is no bug.
High CPU usage isn't necessarily a bad thing if it's non-blocking.
The Editor will now parse (in a thread) as you type and only on idle
activity. When you stop typing for just a fraction of a second Toad uses as
much CPU as it can get to parse as fast as possible. If you start typing
while the Editor is parsing it stops and you should notice no ill effects
from the parsing or momentary periods of high CPU usage. If the parsing has
finished and the navigator tree is populating then there may be a brief
period waiting for the tree to finish loading, but even this should be fast
in moderately large packages and the timing would need to be just right to
experience any delay in this area.
The Editor also smart parses. As you edit text there is a range of text that
has been modified. The text before the range is unmodified and that after
the range is unmodified. The Editor will only parse the text that has been
invalidated by recent modifications. This is pretty efficient.
I think that there is this perception that when an application is pegging a
CPU core that there is a problem and I don't necessarily agree with this
if the application responds quickly to your input. Most new CPUs these days
have up to 8 cores so we should be taking advantage of that, right? It would
be a little overkill to have a quad core (or more) CPU sitting there with
nothing using it.
Thanks for the information and the great support. I’ll just go back to 10.5
until then. Le 2010-10-04 13:42, Mark Lerch a écrit : there will be a patch
in the November time frame
Those are good points, but we are talking about short spikes in CPU usage, not
the normal CPU usage used by Toad for extended periods of time. When I have a
file loaded in the Editor and I am doing nothing Process Explorer isn’t showing
any CPU usage by Toad. When I first load that file it spikes to ~30% and quickly
returned to “normal.” I have seen other larger files spike a single core to the
max and keep it there until done. The original poster’s issue regarding the bug
is definitely a problem and something that is abnormal. My earlier comment was
in regards to an application that must perform some resource intensive tasks
quickly. In that case I don’t see why a non-blocking spike in CPU usage is a bad
thing. Windows is giving Toad that amount of CPU for a thread created as normal
priority. If you have high priority applications then Windows should be giving
those applications precedence if they have their thread priorities set
accordingly.