Comments (18)
You might get lower memory usage by using fewer codegen units.
from gtk.
The solution there is cross-compilation. The rust compiler uses a lot of memory when running, which is an issue (my raspberry 3 cannot use rustc
directly, I cross-compile to it for example). I show an example on how to cross-compile to raspberry here, I guess it's not very different for the pinephone.
As for the rust compiler using too much memory, well, it's not a known issue but luckily, the cross-compilation is pretty easy to use there.
from gtk.
Yes but cross compilation means I can't e.g. compile on the phone itself when I'm on the train. I often don't bring my laptop anymore since it's not that required, and most trains have power outlets here so I don't really mind the power consumption of compilation either. Of course this isn't that useful as a full time dev where this compiling is way too slow, but for some hobby stuff on the side this is very convenient. And some people just starting out in some poorer neighborhoods might only have a raspberry pi to work on, should they never use rust for graphical applications then? So to me this seems a little unfortunate.
Is there an upstream ticket to track this yet? I think it's unfortunate that any GTK+ app dev in rust will be impossible on lower spec devices due to this. (Rather than just inconvenient with expected long compilation times, I understand those cannot be magically avoided in any case.)
from gtk.
Cross compilation is pretty common for any embedded development, even in C/C++. So not sure...
from gtk.
Raspberry pi 2 and newer really doesn't usually count as an embedded platform I don't think. Pretty sure it's a somewhat common entry level device for teenagers and other new tinkerers especially from poorer backgrounds since it is so cheap, often used for python programming on device (I think "pi" even refers to python? I forgot) with a real desktop environment. And at least until recently, 4GB memory was also pretty common for an entry level laptop. Not everyone has a powerful rig, and requiring >2GB for compilation for a regular graphical app seems surprising to me even on a 4GB machine.
Is it really just me who finds it bewildering that with 2GB memory it's not possible to compile a simple GTK hello world app in rust? I'm not from the rust world, to be fair, so I find it even more bewildering that you seem to have just accepted that as the "new normal". I guess if that is what everyone using rust agrees on, who am I to judge. But from the outside looking in this seems really like something that should be addressed to me.
from gtk.
Would this be something to be addressed in the downstream application I reported this from, that is the squeekboard on-screen keyboard I tried to compile?
Also I feel like it wouldn't hurt to poke rustc people about this as well, unless this is an inherent issue somehow caused by and fixable in gtk-rs itself. But from the reactions in chat and here it appears to be common that rustc needs a lot of memory, and not that project-related. So I feel like maybe I should make a rustc issue ticket...?
from gtk.
I think this will have to be reported to rustc itself as a first step. gtk-rs could improve the memory usage by providing a less convenient API. To some degree it could probably also be improved without sacrificing usability, but in the end it's something that has to be improved in the compiler.
from gtk.
Okay, thanks for the info! I forwarded the ticket to here: rust-lang/rust#78308
from gtk.
Hi. I'm the maintainer of Squeekboard, and gtk-rs has been the number one crate giving us trouble in terms of compile-time resource usage. The other problem is taking several minutes compiling for arm64.
While I agree that the problem is partially with rustc and its unreasonable resource usage, in practice this creates a pressure on the downstream maintainer (in this case me) to justify choosing rust/gtk-rs, when the cost is that CI pipelines time out, fellow developers have extended edit/compile/run cycles, or can't even build it on the target device.
Since gtk-rs is a big part of it, I must consider going back to C for GTK, or splitting gtk-rs up into parts, which contain only what I'm using. Of course, that is not beneficial to gtk-rs in any way.
From a practical perspective, I would like to ask about what we can do in the other parts of the stack while we wait for rustc to catch up with the world:
Where does this extra load come from on the gtk-rs side? Is it because of a lot of templating? What are the smallest changes to the API that yield the biggest advantage? Would splitting into more crates achieve anything?
from gtk.
It's the huge number of types in gtk
and the number of traits that come together with those. I think a practical approach that would make things not too bad for users would be to add cargo features to explicitly enable specific parts of the API (and have all enabled by default).
from gtk.
Thanks. I can to allocate some time for a features attempt towards the end of the year.
I'm not a GTK expert… is there a preferred way to slice the features, or should I just try whatever gives good results?
from gtk.
I have no idea really, someone would have to look at this and try to group things in a useful way. I don't really use GTK myself :)
from gtk.
Neither do I (what kind of people are we for maintaining GUI stuff if we don't do GUIs?! 🤣 ). Do you have any ideas how we could split things @ebassi?
from gtk.
Not really. GTK is a complete API, and we have historically resisted any call to slice and dice it (and GLib) up for constrained environments—especially if it's just a side effect of a build-time issues on certain languages.
I honestly don't even know how would you go about it, to be fair; leaf widgets are probably something that can be ignored, unless they are containers? Maybe the file/color/application selection widgets? Or the printing API?
from gtk.
Maybe it would make sense to poke and find out how quickly this could possibly be addressed in rustc? (Edit: I mean also from a practical side, like whether there is manpower for this in the near future at all for this sort of problem) Fwiw I just hoped it would get addressed in the medium to longer term personally, although from @dcz-purism 's remarks it sounds like it's a somewhat acute problem for some people right now. I don't want to stop anyone from any intermediate solutions of course if you want to do them, just my two cents
from gtk.
I don't really know what would be needed on the rustc side. I never tried to hack on it yet, but considering how often I see people complaining about build times, I suspect that low hanging fruits have been picked there.
from gtk.
Hm but I do wonder if that is also the case for the memory usage? Although if the CI timeouts impact you more, I understand that is possibly not your main concern. For on device builds however I feel like memory really is the main issue.
from gtk.
Limiting compilation unit size is the starting point both for memory and CPU usage. This needs to be tried and then we'll see.
from gtk.
Related Issues (20)
- constants GDK_BUTTON_* missing? HOT 3
- are we sure destroy() is never needed? HOT 9
- What is the best way to make integration tests with GTK? HOT 4
- Include libportal in gtk-rs? HOT 4
- Null pointer panic on `GestureZoom::connect_end` HOT 4
- Crash when touching entry icon HOT 8
- Cannot add new tabs in GtkNotebook HOT 3
- glib and gio compatibility scheme HOT 4
- FileChooserNative memory management issue HOT 4
- Broken requirements URL in README.md HOT 6
- Broken README link
- gtk::PopoverMenu::popup doesn't work for PopoverMenu HOT 4
- Problems with `gtk::Image` update through `Pixbuf` HOT 1
- Using from another package fails on Windows with GLib-GIO-CRITICAL ** This application can not open files. HOT 2
- Pressing the mouse button yields two button events HOT 4
- GestureDrag does not signal events HOT 1
- Support GTK 4 HOT 2
- Add GtkImageMenuItem support HOT 1
- GLArea and OpenGL
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gtk.