[geda-user] A different kind of gschem nap

[Kai-Martin Knaak]

While I was with my guinea pig schematics to provoke the nap I complained
about in the other thread, I stumbled on a different kind of nap. This
one is more pronounced. It took 15 minutes on my current private desktop.
To reproduce:

1) enable auto-number with these lines in gschemrc:
(load-from-path "auto-uref.scm")
(define auto-uref-set-page-offset 100)
(add-hook! add-component-hook auto-uref)
(add-hook! copy-component-hook auto-uref)

2) start gschem with the schematic pidpeltier.sch I supplied in the other
nap thread.

3) select the whole schematic with [crtl-a]

4) copy the schematic to some other place
gschem remains unresponsive for a few minutes. One processor core is on full
load.


In gprof output the function o_redraw leads the list again:
/------------------
% cumulative self self total
time seconds seconds calls us/call us/call name
55.56 0.05 0.05 149 335.57 335.57 o_redraw_rects
11.11 0.06 0.01 165189 0.06 0.06 gschem_page_view_get_page
11.11 0.07 0.01 2632 3.80 3.80 gschem_page_geometry_mil_x
11.11 0.08 0.01 2632 3.80 3.80 gschem_page_geometry_mil_y
11.11 0.09 0.01 x_event_button_released
0.00 0.09 0.00 110736 0.00 0.00 gschem_page_geometry_set_values
0.00 0.09 0.00 110736 0.00 0.06 gschem_page_view_get_page_geometry
0.00 0.09 0.00 110736 0.00 0.00 update_constants
0.00 0.09 0.00 107955 0.00 0.00 gschem_page_geometry_pix_x
0.00 0.09 0.00 107955 0.00 0.00 gschem_page_geometry_pix_y
0.00 0.09 0.00 107955 0.00 0.06 gschem_page_view_WORLDtoSCREEN
0.00 0.09 0.00 54034 0.00 0.06 gschem_page_view_SCREENabs
0.00 0.09 0.00 53959 0.00 0.06 gschem_page_view_invalidate_screen_rect
0.00 0.09 0.00 53959 0.00 0.18 gschem_page_view_invalidate_world_rect
0.00 0.09 0.00 18720 0.00 0.00 find_single_object
0.00 0.09 0.00 18720 0.00 0.00 is_object_hit
0.00 0.09 0.00 7578 0.00 0.00 gschem_toplevel_get_toplevel
0.00 0.09 0.00 5419 0.00 0.00 gschem_options_get_snap_size
0.00 0.09 0.00 5237 0.00 0.00 gschem_options_get_snap_mode
0.00 0.09 0.00 5190 0.00 0.00 snap_grid
0.00 0.09 0.00 3646 0.00 0.00 g_dynwind_window
0.00 0.09 0.00 3646 0.00 0.00 g_scm_from_window
0.00 0.09 0.00 2632 0.00 7.66 gschem_page_view_SCREENtoWORLD
0.00 0.09 0.00 1042 0.00 0.00 g_get_hook_by_name
0.00 0.09 0.00 1041 0.00 0.00 g_run_hook_object
0.00 0.09 0.00 1041 0.00 0.00 o_attrib_select_invisible
0.00 0.09 0.00 1041 0.00 0.00 o_select_object
0.00 0.09 0.00 1041 0.00 0.00 o_select_run_hooks
0.00 0.09 0.00 572 0.00 0.00 gschem_accel_label_get_type
0.00 0.09 0.00 478 0.00 0.00 gschem_page_view_get_type
0.00 0.09 0.00 425 0.00 0.00 x_menus_sensitivity
(...)
\------------------


If I do the same copy/paste operation without the autonumber hooks, gschem
returns immediately. Seems like the renumber hook triggers lots of redraw
events.

The stock binary from the debian repository, gschem 1.8.2, shows the same
symptoms but even longer -- 20 minutes.

---<)kaimartin(>---

[Edward Hennessy]

Post by Kai-Martin Knaak
While I was with my guinea pig schematics to provoke the nap I complained
about in the other thread, I stumbled on a different kind of nap. This
one is more pronounced. It took 15 minutes on my current private desktop.
(load-from-path "auto-uref.scm")
(define auto-uref-set-page-offset 100)
(add-hook! add-component-hook auto-uref)
(add-hook! copy-component-hook auto-uref)
2) start gschem with the schematic pidpeltier.sch I supplied in the other
nap thread.
3) select the whole schematic with [crtl-a]
4) copy the schematic to some other place
gschem remains unresponsive for a few minutes. One processor core is on full
load.

I've reproduced the issue on my machine and profiled execution using valgrind/callgrind and kcachegrind.

The function s_weakref_remove() is taking up a large percentage of the execution time. (More than 85%)
And, this function is called from smob_free().

Using a faster container to store weak references could put us into the 2-3 min range.

Does anybody know if something can be done on the scheme side to improve performance?

Cheers,
Ed

[Kai-Martin Knaak]

Post by Edward Hennessy
The function s_weakref_remove() is taking up a large percentage of
the execution time. (More than 85%) And, this function is called
from smob_free().
Using a faster container to store weak references could put us into the 2-3 min range.

This still seems ridiculously inefficient to me. The algorithm jut
needs to assign about 100 refdes numbers that are not yet used. This
should not take minutes on a contemporary desktop.

I tried to use the autonumber dialog that can be from inside the
gschem UI (Attributes->Autonumber_Text). It returns immediately within
less than 0.1 s. Maybe, it is possible to hook into whatever method
this renumber path uses. It could use the same options as the
interactive dialog. I for one would welcome the additional user
control on the process.

---<)kaimartin(>---

[Edward Hennessy]

Post by Kai-Martin Knaak

Post by Edward Hennessy
The function s_weakref_remove() is taking up a large percentage of
the execution time. (More than 85%) And, this function is called
from smob_free().
Using a faster container to store weak references could put us into the 2-3 min range.

This still seems ridiculously inefficient to me. The algorithm jut
needs to assign about 100 refdes numbers that are not yet used. This
should not take minutes on a contemporary desktop.

There is room for improvement. I don't have enough proficiency with
scheme to look into it. Hopefully, one of the developers proficient
with scheme will be able to.

Are other developers ok with moving this functionality into C as
opposed to scheme?

Cheers,
Ed

[Kai-Martin Knaak]

Post by Edward Hennessy
I don't have enough proficiency with
scheme to look into it.

Me neither.

Post by Edward Hennessy
Hopefully, one of the developers proficient with scheme will be able to.

Is there currently more than one? (Peter Brett)

---<)kaimartin(>---

[Edward Hennessy]

Post by Kai-Martin Knaak

Post by Edward Hennessy
The function s_weakref_remove() is taking up a large percentage of
the execution time. (More than 85%) And, this function is called
from smob_free().
Using a faster container to store weak references could put us into the 2-3 min range.

This still seems ridiculously inefficient to me. The algorithm jut
needs to assign about 100 refdes numbers that are not yet used. This
should not take minutes on a contemporary desktop.

I'm working on something that may help. I wrote some scheme to reset
refdes when copying and pasting. It can be added to the local
configuration with:

(load-from-path "auto-refdes.scm")
(add-hook! copy-objects-hook auto-refdes-reset!)

It doesn't reset refdes when cutting and multiple pasting, yet.

Cheers,
Ed