After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580056 - Use multiple threads for puzzle generation
Use multiple threads for puzzle generation
Status: RESOLVED FIXED
Product: gnome-sudoku
Classification: Applications
Component: general
git master
Other All
: High enhancement
: ---
Assigned To: gnome-sudoku-maint
gnome-sudoku-maint
Depends on:
Blocks: 731215
 
 
Reported: 2009-04-24 00:19 UTC by Avery Fay
Modified: 2014-08-18 18:09 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Avery Fay 2009-04-24 00:19:42 UTC
puzzle generation is really slow if only want "hard" or "very hard" puzzles. (it took a number of minutes to generate 100 hard puzzles... would be worse for very hard puzzles) Theoretically, using multiple cores for the generation would speed this up quite a bit.
Comment 1 Michael Catanzaro 2014-08-07 00:54:33 UTC
We should be much faster now that we use qqwing to generate puzzles, but there's still a noticeable hang when printing 100 puzzles at a time. We need to make sure we never generate puzzles in the UI thread and start a spinner if we're generating enough puzzles at once for the delay to be noticeable.

Optionally, we can split the work between existing threads. To find out how many CPUs to use, you can use libgtop [1] since pretty much any other way you can think of to do this on Linux won't be portable. I think/hope the answer we want is simply glibtop_get_sysinfo().ncpu.

[1] https://developer.gnome.org/libgtop/stable/libgtop-sysinfo.html
Comment 2 Parin Porecha 2014-08-18 18:09:49 UTC
The branch for this feature has been merged with master at 1e7d1ec.

Since libgtop doesn't have a .vapi, I've called nproc through GLib.Process to find out the no. of CPUs.