Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add caching #100

Open
phil294 opened this issue Jul 19, 2022 · 2 comments
Open

Add caching #100

phil294 opened this issue Jul 19, 2022 · 2 comments

Comments

@phil294
Copy link

phil294 commented Jul 19, 2022

Hi!
Is there any reason the the bindings need to be generated at every build time? It seems to take around three seconds for every build. Crystalline, the best and only Crystal IDE supporting tool I know of, is also based on the compiler and thus now every go-to and autocomplete request takes super long.

I think some kind of caching command would be great. In a local scenario of mine, I replaced all require_gobject calls with its respective build_namespace output counterparts, and it works great and build time is now harmless again. And it also gives me a nice (albeit huge) file where I can look up the proper generated GTK function and class names for the job.

Caching comes with its downsides of course, but I think in this case it's very justifiable. I personally now don't need this feature anymore, but I wanted to share my experiences with it anyway :-)

@hugopl
Copy link
Contributor

hugopl commented Jul 19, 2022

Not really, the generator is ran by the macro, the generator compilation is cached, for usual code-compile-run cycle it really doesn't make so much difference... but for crystalline it sure does.

BTW it is always good to distribute the generated code in the source release, since libraries update can break the compilation in the future.

As an example, the last version of my app fail to compile with this shard due to some recent library update, the generator just generates bad code, as I'm working on the GTK4 version and didn't have to compile it again yet I didn't care too much.

But... I think it's not good to have the generated code in the repository, however is recommended to have the generated code in the tar.gz used for source releases.

@phil294
Copy link
Author

phil294 commented Aug 22, 2022

for usual code-compile-run cycle it really doesn't make so much difference

Ok so there seems to be some kind of caching indeed. Some anecdotal (but consistent) performance tests on a 800 MHz machine: First build after install: 31.4s, repeated compilation: 20.8s, repeated compilation with manual caching as described above: 15.2. With 2.8 GHz, the savings go from 6.4s to 4.7.

So yeah it's not the world, but would be noticeable.

Thanks for your explanation. Gtk4 sounds awesome. I don't need it but it will most likely become quite significant in the next years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants