[geda-user] gschem sometimes takes a nap

[Kai-Martin Knaak]

Hi.
When working with gschem I get occasional transient freezes. The freeze
usually happens right after I selected a substantial portion of the
schematic. During the freeze one of the processor kernels runs on full
load. The duration of the freeze varies. On my current three months old
desktop (quad i5, 8GB RAM, SSD) the freeze tends to be a couple of
seconds. On the previous machine it took significantly longer.

After the nap, the GUI returns and works like nothing happened.
I had this since a year or two. But lately they tend to be more frequent.

Am I the only one who experiences these freezes?
Anything I can do to pin down the culprit?

---<)kaimartin(>---

[Dave McGuire]

I've seen this behavior on occasion as well. It doesn't last long enough to really bother me though.

-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA

Post by Kai-Martin Knaak
Hi.
When working with gschem I get occasional transient freezes. The freeze
usually happens right after I selected a substantial portion of the
schematic. During the freeze one of the processor kernels runs on full
load. The duration of the freeze varies. On my current three months old
desktop (quad i5, 8GB RAM, SSD) the freeze tends to be a couple of
seconds. On the previous machine it took significantly longer.
After the nap, the GUI returns and works like nothing happened.
I had this since a year or two. But lately they tend to be more frequent.
Am I the only one who experiences these freezes?
Anything I can do to pin down the culprit?
---<)kaimartin(>---
--
Kai-Martin Knaak tel: [phone]
Universität Hannover, Inst. für Quantenoptik fax: [phone]
Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de
GPG key: http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get

[Larry Doolittle]

Firends -

Post by Dave McGuire
I've seen this behavior on occasion as well. It doesn't last long enough to really bother me though.

Post by Kai-Martin Knaak
When working with gschem I get occasional transient freezes.

Shot in the dark: guile garbage-collecting?

- Larry

[Joshua Lansford]

Post by Kai-Martin Knaak
Am I the only one who experiences these freezes?
Anything I can do to pin down the culprit?
---<)kaimartin(>---

I have had these freezes as well. I had thought it seemed to be correlated
to the content in a schematic. Not the quantity of stuff but perhaps
pathological boundary cases.
~Joshua

[Edward Hennessy]

Sent from my iPhone

Post by Kai-Martin Knaak
Am I the only one who experiences these freezes?
Anything I can do to pin down the culprit?
---<)kaimartin(>---

I have had these freezes as well. I had thought it seemed to be correlated to the content in a schematic. Not the quantity of stuff but perhaps pathological boundary cases.
~Joshua

I attempted to replicate the issue with one of my schematics, and could not get any perceptible freeze. Nothing showed up on the CPU strip chart in the system monitor. Does anyone have a schematic that can replicate the issue that would be available for me to use?

I tried getting gprof to work with gschem this morning. No gmon.out is getting generated. I suspect an issue with the instrumentation code not getting called at exit(). Has anyone got gprof working with gschem before?

Cheers,
Ed

[Nathan Stewart]

I haven't messed with my project in a while, but I was seeing it often with
some heavily nested schematics
I rather suspect it might be related to a problem schematic/symbol or gafrc
issue rather than simply volume or depth of nesting

I'll see if I can reproduce later tonight.

I haven't messed with my project in a while, but I was seeing it often
with some heavily nested schematics
I rather suspect it might be related to a problem schematic/symbol or
gafrc issue rather than simply volume or depth of nesting
I'll see if I can reproduce later tonight.

Post by Edward Hennessy
Sent from my iPhone
On Sep 4, 2014, at 8:33 AM, Joshua Lansford <
On Wed, Sep 3, 2014 at 6:06 PM, Kai-Martin Knaak <

Post by Kai-Martin Knaak
Am I the only one who experiences these freezes?
Anything I can do to pin down the culprit?
---<)kaimartin(>---

I have had these freezes as well. I had thought it seemed to be
correlated to the content in a schematic. Not the quantity of stuff but
perhaps pathological boundary cases.
~Joshua
I attempted to replicate the issue with one of my schematics, and could
not get any perceptible freeze. Nothing showed up on the CPU strip chart in
the system monitor. Does anyone have a schematic that can replicate the
issue that would be available for me to use?
I tried getting gprof to work with gschem this morning. No gmon.out is
getting generated. I suspect an issue with the instrumentation code not
getting called at exit(). Has anyone got gprof working with gschem before?
Cheers,
Ed

[Kai-Martin Knaak]

Post by Edward Hennessy
Does anyone have a schematic that can replicate
the issue that would be available for me to use?

See my schematics guinea pig in the attachment. I was able to trigger the
freeze by moving chunks of the schematic around.

Post by Edward Hennessy
I tried getting gprof to work with gschem this morning. No gmon.out is
getting generated. I suspect an issue with the instrumentation code not
getting called at exit(). Has anyone got gprof working with gschem
before?

I had not heard about gprof before. The man page talked about binaries
compiled with the -pg option. The configure script of gschem reads the
environment variable $CFLAGS. So I set it to
export CFLAGS=-pg
After I resolved an issue with not included <locale.h>, I got an binary
that generates a gmon.out. I will attach the output of gprof from a
session with a significant freeze in my next post.

---<)kaimartin(>---

[Edward Hennessy]

Post by Kai-Martin Knaak

Post by Edward Hennessy
Does anyone have a schematic that can replicate
the issue that would be available for me to use?

See my schematics guinea pig in the attachment. I was able to trigger the
freeze by moving chunks of the schematic around.

I believe I've reproduced the issue on my machine with your schematic. I can
sometimes get gschem to freeze a bit when moving objects around. However, when
selecting all objects on the schematic using Ctrl-A, my gschem will freeze for
five seconds.

When this freeze occurs, the function o_redraw_rects() is getting called with
over 6000 rectangles. And, it appears the time is spent repainting the background.

Shutting off the grid or switching to dots makes the problem much less pronounced.

Does this description match what you are seeing?

Post by Kai-Martin Knaak

Post by Edward Hennessy
I tried getting gprof to work with gschem this morning. No gmon.out is
getting generated. I suspect an issue with the instrumentation code not
getting called at exit(). Has anyone got gprof working with gschem
before?

I had not heard about gprof before. The man page talked about binaries
compiled with the -pg option. The configure script of gschem reads the
environment variable $CFLAGS. So I set it to
export CFLAGS=-pg
After I resolved an issue with not included <locale.h>, I got an binary
that generates a gmon.out. I will attach the output of gprof from a
session with a significant freeze in my next post.

Unfortunately, I still don't have any luck generating a gmon.out. I've used the
flags and can see the instrumentation in my object code, but it still doesn't
generate gmon.out. Just curious, what version of gcc did you compile with?

Cheers,
Ed

[Edward Hennessy]

Post by Edward Hennessy

Post by Kai-Martin Knaak

Post by Edward Hennessy
Does anyone have a schematic that can replicate
the issue that would be available for me to use?

See my schematics guinea pig in the attachment. I was able to trigger the
freeze by moving chunks of the schematic around.

I believe I've reproduced the issue on my machine with your schematic. I can
sometimes get gschem to freeze a bit when moving objects around. However, when
selecting all objects on the schematic using Ctrl-A, my gschem will freeze for
five seconds.
When this freeze occurs, the function o_redraw_rects() is getting called with
over 6000 rectangles. And, it appears the time is spent repainting the background.
Shutting off the grid or switching to dots makes the problem much less pronounced.
Does this description match what you are seeing?

A potential fix is checked into source control. Hopefully, it isn't just tuned to execute faster on my machine.

Something not intuitive is going on under the hood:

- The change in x_event.c reduces the number of invalid rectangles to one - yields a speed improvement
- The change in x_grid.c moves the cairo_stroke() into the for loop - performance actually gets WORSE
- When both changes are combined - performance is much faster than the changes in x_event.c alone

I've been able to resize the gschem window and get the naptime up to 10 seconds. These two changes reduce the time, under the same conditions, to about 1 second.

Cheers,
Ed

[Peter Clifton]

Post by Edward Hennessy
A potential fix is checked into source control. Hopefully, it isn't just tuned to execute faster on my machine.
- The change in x_event.c reduces the number of invalid rectangles to one - yields a speed improvement
- The change in x_grid.c moves the cairo_stroke() into the for loop - performance actually gets WORSE
- When both changes are combined - performance is much faster than the changes in x_event.c alone

Presumably you are seeing a trade-off between painting lots of small
pieces of the screen, and painting the whole screen in one hit. Gschem
isn't very efficient at mapping the small regions into a list of objects
to paint.

I'd suggest looking at whether there is a heuristic you can apply for
the operations which cause a certain amount of redraw, to force a redraw
of the whole screen rather than the individual areas.

It might be worth looking at whether invalidating the whole screen for
_every_ update is actually a pragmatic way to proceed.

If you invalidate the whole screen area, GDK _should_ subsume the small
regions into the larger one.

Now most X11 desktops have moved away from a model where you get
individual small expose events, so painting exposed regions uncovered by
moving other windows is not really a concern nowadays. All the drawing
is triggered by us.

[Peter Clifton]

Post by Edward Hennessy
A potential fix is checked into source control. Hopefully, it isn't just tuned to execute faster on my machine.
- The change in x_event.c reduces the number of invalid rectangles to one - yields a speed improvement
- The change in x_grid.c moves the cairo_stroke() into the for loop - performance actually gets WORSE
- When both changes are combined - performance is much faster than the changes in x_event.c alone

Presumably you are seeing a trade-off between painting lots of small
pieces of the screen, and painting the whole screen in one hit. Gschem
isn't very efficient at mapping the small regions into a list of objects
to paint.

I'd suggest looking at whether there is a heuristic you can apply for
the operations which cause a certain amount of redraw, to force a redraw
of the whole screen rather than the individual areas.

It might be worth looking at whether invalidating the whole screen for
_every_ update is actually a pragmatic way to proceed.

If you invalidate the whole screen area, GDK _should_ subsume the small
regions into the larger one.

Now most X11 desktops have moved away from a model where you get
individual small expose events, so painting exposed regions uncovered by
moving other windows is not really a concern nowadays. All the drawing
is triggered by us.

[Peter Clifton]

Post by Edward Hennessy
A potential fix is checked into source control. Hopefully, it isn't just tuned to execute faster on my machine.
- The change in x_event.c reduces the number of invalid rectangles to one - yields a speed improvement
- The change in x_grid.c moves the cairo_stroke() into the for loop - performance actually gets WORSE
- When both changes are combined - performance is much faster than the changes in x_event.c alone

Presumably you are seeing a trade-off between painting lots of small
pieces of the screen, and painting the whole screen in one hit. Gschem
isn't very efficient at mapping the small regions into a list of objects
to paint.

I'd suggest looking at whether there is a heuristic you can apply for
the operations which cause a certain amount of redraw, to force a redraw
of the whole screen rather than the individual areas.

It might be worth looking at whether invalidating the whole screen for
_every_ update is actually a pragmatic way to proceed.

If you invalidate the whole screen area, GDK _should_ subsume the small
regions into the larger one.

Now most X11 desktops have moved away from a model where you get
individual small expose events, so painting exposed regions uncovered by
moving other windows is not really a concern nowadays. All the drawing
is triggered by us.

[Edward Hennessy]

Post by Peter Clifton
I'd suggest looking at whether there is a heuristic you can apply for
the operations which cause a certain amount of redraw, to force a redraw
of the whole screen rather than the individual areas.
It might be worth looking at whether invalidating the whole screen for
_every_ update is actually a pragmatic way to proceed.
If you invalidate the whole screen area, GDK _should_ subsume the small
regions into the larger one.

The commit improves performance by about 10:1. If the users don't complain,
I'm calling this one done.

Cheers,
Ed

[Kai-Martin Knaak]

Post by Edward Hennessy
A potential fix is checked into source control. Hopefully, it isn't
just tuned to execute faster on my machine.

Just compiled fresh from git head. It looks like your fix is indeed an
improvement. I was not able to provoke the naps like before. My
current project at my day job had me waiting for geschem a few times
per hour. I will work on it again tomorrow -- will report on the
mileage of the patched gschem.

---<)kaimartin(>---

[Kai-Martin Knaak]

will report on the mileage of the patched gschem.

Unfortunately, I feel no much difference. While working on my project, I
still get a five second timeout every ten minutes. These generally occur
after I selected something -- that is, no move involved.

Curiously, I was never able to immediately get another timeout by
repeating whatever I just did.

---<)kaimartin(>---

[Edward Hennessy]

Post by Kai-Martin Knaak
Unfortunately, I feel no much difference. While working on my project, I
still get a five second timeout every ten minutes. These generally occur
after I selected something -- that is, no move involved.

I haven't been able to reproduce the issue on my machine with the following:

- Alternating Ctrl-A and Ctrl-Shift-A to select all and unselect all
- Selecting random rectangles
- Alternating selecting two different objects with single clicks

Do you have any more info that could help me reproduce the issue?

Cheers,
Ed

[Kai-Martin Knaak]

Post by Edward Hennessy
Unfortunately, I still don't have any luck generating a gmon.out.
I've used the flags and can see the instrumentation in my object
code, but it still doesn't generate gmon.out. Just curious, what
version of gcc did you compile with?

I used gcc 4.9.1 as packaged by debian/testing.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.9.1-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --
enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --
program-suffix=-4.9 --enable-shared --enable-linker-build-id --
libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --
enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-
debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --
disable-vtable-verify --enable-plugin --with-system-zlib --disable-
browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-
home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --
with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-
jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-
directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --
enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-
tune=generic --enable-checking=release --build=x86_64-linux-gnu --
host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-4)

---<)kaimartin(>---

[Kai-Martin Knaak]

Here is the output of gprof after gschem suffered from a noticeable
freeze.
There is one function that seems to stand out: o_redraw_rects
I attached a second file with gprof output on a session with no
noticeable freeze. The function o_redraw_rects is still on top of the
list, but not that far ahead.

---<)kaimartin(>---

[Edward Hennessy]

Post by Kai-Martin Knaak
Here is the output of gprof after gschem suffered from a noticeable
freeze.
There is one function that seems to stand out: o_redraw_rects
I attached a second file with gprof output on a session with no
noticeable freeze. The function o_redraw_rects is still on top of the
list, but not that far ahead.

Thank you. This info help immensely.

Cheers,
Ed