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 754164 - Performance of vapigen is slow when using GIR files
Performance of vapigen is slow when using GIR files
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: Bindings
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2015-08-27 10:44 UTC by Garrett Regier
Modified: 2018-05-22 15:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The script used to generate the GIR. (8.69 KB, text/x-python)
2015-08-27 10:45 UTC, Garrett Regier
  Details
girparser: Cache the cprefix and csuffix (3.37 KB, patch)
2015-08-27 10:50 UTC, Garrett Regier
none Details | Review
girparser: Improve find_parent() performance (3.09 KB, patch)
2015-08-27 10:59 UTC, Garrett Regier
none Details | Review
gee: Replace HashMap and HashSet implementation (14.44 KB, patch)
2015-08-27 11:00 UTC, Garrett Regier
none Details | Review
markupreader: Various performance improvements (11.89 KB, patch)
2015-08-27 11:05 UTC, Garrett Regier
none Details | Review

Description Garrett Regier 2015-08-27 10:44:07 UTC
There is a serious performance issue with large GIR files and it is causing vapigen to run for just over 2 minutes in my test case. The GIR files in question are generated and I'm attaching a representative example that I've generated. It might be interesting to include this GIR or the script to avoid future performance regressions.
Comment 1 Garrett Regier 2015-08-27 10:45:31 UTC
Created attachment 310081 [details]
The script used to generate the GIR.

The GIR file was too big...
Comment 2 Luca Bruno 2015-08-27 10:48:16 UTC
So where is a real-life project which generates a GIR that runs for 2 minutes?
Comment 3 Garrett Regier 2015-08-27 10:50:17 UTC
Created attachment 310084 [details] [review]
girparser: Cache the cprefix and csuffix

This drastically improves performance, especially for larger GIR files.

Before: 139.38 seconds
After: 31.27 seconds
Comment 4 Garrett Regier 2015-08-27 10:59:04 UTC
Created attachment 310085 [details] [review]
girparser: Improve find_parent() performance

This is especially useful for larger GIR files.

Before: 31.27 seconds
After: 5.13 seconds
Comment 5 Garrett Regier 2015-08-27 11:00:39 UTC
Created attachment 310086 [details] [review]
gee: Replace HashMap and HashSet implementation

Instead use GLib.HashTable which has improved performance.

This improves parsing large GIR files:
Before: 5.13 seconds
After: 4.46 seconds


GHashTable now has an optimization for using it as a set which avoids allocating storage for the values when not needed.
Comment 6 Garrett Regier 2015-08-27 11:05:14 UTC
Created attachment 310087 [details] [review]
markupreader: Various performance improvements

This improves parsing large GIR files:
Before: 4.46 seconds
After: 3.95 seconds


The generated GIR is not seeing all of the performance improvements as it does not contain any embedded documentation.
Comment 7 Garrett Regier 2015-08-27 11:07:10 UTC
(In reply to Luca Bruno from comment #2)
> So where is a real-life project which generates a GIR that runs for 2
> minutes?

It is an internal application, and unfortunately there are quite a few vapigen calls which end up taking up a large amount of the build time.
Comment 8 Luca Bruno 2015-08-27 12:26:36 UTC
I've applied the "Cache the cprefix and csuffix" and "Improve find_parent() performance" patches and regenerated all the bindings. No diff, but time to generate is the same as before.

Will investigate a little more with your gir.
Comment 9 Garrett Regier 2015-10-06 08:36:24 UTC
ping?
Comment 10 GNOME Infrastructure Team 2018-05-22 15:26:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/509.