Hi all,
when running query tasks like d.what.rast I get 100% system load. Is that normal?
I'm running Grass under cygwin (in the cycwin-installer it is listed with 6.1.csv-7)
Regards
Wolfgang
On Apr 23, 2006, at 4:58 PM, Wolfgang wrote:
when running query tasks like d.what.rast I get 100% system load. Is that normal?
I'm running Grass under cygwin (in the cycwin-installer it is listed with 6.1.csv-7)
I get similar behavior running GRASS on Gentoo Linux and on older builds for OS X, though recent (say, since February/March of this year) builds for Mac OS X don't have that problem, provided GRASS remains as the frontmost window. Similarly, older builds of v.digit also claimed 100% of the processor, but again, recent builds for Mac OS X do not.
In Gentoo, v.digit only claims about 15% of the processor, but X is claiming 85%.
Jesse
If you use the new GUI GIS Manager (you still have to type gis.m& to start
it, but that will change soon), you should no longer have this problem for
queries, zoom, pan, or measure. These are all done in TclTk and so don't eat
up your CPU cycles. V.digit and i.points still run in xwindows displays and
will have this problem. I hope to be able to create a TclTk version of
i.points at least pretty soon (this summer?).
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Jesse Hamner <jhamner@emory.edu>
Date: Sun, 23 Apr 2006 17:37:52 -0400
To: Wolfgang <wollez@gmx.net>
Cc: <grasslist@baylor.edu>
Subject: [GRASSLIST:827] Re: performance problems with mouse query in
displaysOn Apr 23, 2006, at 4:58 PM, Wolfgang wrote:
when running query tasks like d.what.rast I get 100% system load.
Is that normal?I'm running Grass under cygwin (in the cycwin-installer it is
listed with 6.1.csv-7)I get similar behavior running GRASS on Gentoo Linux and on older
builds for OS X, though recent (say, since February/March of this
year) builds for Mac OS X don't have that problem, provided GRASS
remains as the frontmost window. Similarly, older builds of v.digit
also claimed 100% of the processor, but again, recent builds for Mac
OS X do not.In Gentoo, v.digit only claims about 15% of the processor, but X is
claiming 85%.Jesse
when running query tasks like d.what.rast I get 100% system load. Is
that normal?I'm running Grass under cygwin (in the cycwin-installer it is listed
with 6.1.csv-7)
Known issue which is being worked on,
https://intevation.de/rt/webrt?serial_num=3087
Please read this thread from the devel list (ongoing):
http://thread.gmane.org/gmane.comp.gis.grass.devel/11798
d.zoom, etc should be working ok as of 21 March; v.digit, d.what.vect
tcltk "Forms" still have problems.
Hamish
On Sun, 23 Apr 2006 22:27:05 -0700
Michael Barton <michael.barton@asu.edu> wrote:
If you use the new GUI GIS Manager (you still have to type gis.m& to
start it, but that will change soon), you should no longer have this
problem for queries, zoom, pan, or measure. These are all done in
TclTk and so don't eat up your CPU cycles. V.digit and i.points still
run in xwindows displays and will have this problem.
Fortunatelly it isn't true anymore. d.* commands were fixed not to
load 100% CPU during mouse ops. It has just been confirmed on the dev
list. The fix was by Radim:
Hamish wrote on dev list:
http://grass.itc.it/pipermail/grass-commit/2006-March/021143.html
http://grass.itc.it/pipermail/grass-commit/2006-March/021144.html
etc.
The remaining CPU hog at query with d.what.vect in TCLTK mode (eg. the
-e switch) and v.digit is the form library. According to top, form
takes 40-60 % of total CPU and Xorg takes 20-40%. (Ubuntu Breezy.)
Despite of this, things are now better - as xwindows displays don't
offend CPU anymore (they load max few %) TCLTK form mode has become
much more responsive and real-time editing of attributes is finally
possible. Though it would be neat to have form CPU load by form
reduced to a decent level before the release, if possible.
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
v.digit and d.what.vect were also fixed:
http://grass.itc.it/pipermail/grass-commit/2006-March/021160.html
Do you have still problems even with this fix?
Radim
On 4/24/06, Maciek Sieczka <werchowyna@epf.pl> wrote:
On Sun, 23 Apr 2006 22:27:05 -0700
Michael Barton <michael.barton@asu.edu> wrote:> If you use the new GUI GIS Manager (you still have to type gis.m& to
> start it, but that will change soon), you should no longer have this
> problem for queries, zoom, pan, or measure. These are all done in
> TclTk and so don't eat up your CPU cycles. V.digit and i.points still
> run in xwindows displays and will have this problem.Fortunatelly it isn't true anymore. d.* commands were fixed not to
load 100% CPU during mouse ops. It has just been confirmed on the dev
list. The fix was by Radim:Hamish wrote on dev list:
> http://grass.itc.it/pipermail/grass-commit/2006-March/021143.html
> http://grass.itc.it/pipermail/grass-commit/2006-March/021144.html
> etc.The remaining CPU hog at query with d.what.vect in TCLTK mode (eg. the
-e switch) and v.digit is the form library. According to top, form
takes 40-60 % of total CPU and Xorg takes 20-40%. (Ubuntu Breezy.)Despite of this, things are now better - as xwindows displays don't
offend CPU anymore (they load max few %) TCLTK form mode has become
much more responsive and real-time editing of attributes is finally
possible. Though it would be neat to have form CPU load by form
reduced to a decent level before the release, if possible.Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
On Apr 26, 2006, at 4:53 AM, Radim Blazek wrote:
v.digit and d.what.vect were also fixed:
http://grass.itc.it/pipermail/grass-commit/2006-March/021160.html
Do you have still problems even with this fix?
Here's what I have observed.
Versions:
Mac OS X, 10.4.6 (Dual G5): April 8th GRASS executable (Moretti binaries)
Gentoo Linux (P4 Dell), 2.6 kernel: GRASS compiled from source using April 1st cvs
v.digit:
on Mac OS X: 15% both processors, unless another window is covering the buttons on the v.digit display--then ~70% on both processors.
on Gentoo Linux: 85% X, 14% v.digit
d.what.vect map=mapname (with or without the -e flag) :
on Mac OS X: 80% loading on both processors
on Gentoo Linux: 47% for X, 50% for 'form' (the display of the 'what is here' output)
Older versions of v.digit and d.what.vect really did peg the Mac's processors at 100% each, though.
Hope this observation helps.
Jesse