4 ms·
I'm not familiar with fuschia but those times are what I'd consider normal for an initial compilation of an operating system in regular consumer workstations.
by defer 5y ago
I'm not familiar with fuschia but those times are what I'd consider normal for an initial compilation of an operating system in regular consumer workstations.
I work on the android operating system and very rarely compile the whole thing from scratch in development environments. Incremental builds plus adb sync (think rsync between compiled artifacts in host and device) make it into a manageable workflow.
Even incrementally, it takes a few minutes to see your changes and that can be a source of frustration for newcomers who are used to instant feedback. Being productive requires making good decisions on how often and what to compile as well as strategies for filling up compilation time.
- dalbasal 5y agoThe last sentence is an eyebrow raiser
- defer 5y agoYeah, I mentioned it because I see peers doing different things to be productive during compilation times while newcomers will stare at compiler output. Some will jump to writing documentation, take care of issue management, work on some other ticket entirely, etc.
- spoiler 5y agoI'm vastly oversimplifying the issue (also I'm not a doctor), but didn't studies show that this type of multitasking is bad for our mental health and increases the likelihood of burnout?
- defer 5y agoIt's certainly possible, I honestly wouldn't know. Anedoctaly, I find it worse on my mental health to just sit around waiting for things to finish.
- simonh 5y agoNot a doctor either, just going on articles I've read on this. The sort of multitasking that causes those problems is when both tasks need frequent attention. If you can essentially leave a task alone for several hours, with some sort of notification if there's a problem, that's fine. Even things that don't take much attention but are ongoing tasks, like doing the ironing, are fine depending what else you're combining it with.
- defer 5y agoThis resonates. I usually wrap my long running commands in something that sends a push notification when they finish so that I don't jump around seeing if things completed or failed. I find the distraction of the push notification less disrupting than continually checking for completeness.
- jfoutz 5y agoosx comes with a command "say" which is a text to speech tool. I'd do things like make && say "build complete" || say "compile failed" with different voices I thought were funny. generally worked great. One day, I stepped away and had a particularly intimidating voice say "your build has failed" and apparently knocked out my headphones. I came back just in time to hear that, and see a couple coworkers jump at the sound. After that, I was much more consistent at disabling sound when I stepped away. I got a little teasing about that day, but generally it worked great.
- jfoutz 5y agofast cycles are liberating, because it's easy to just ask the compiler or your testing harness if you're doing the right thing. I can't speak for the parent, but in my experience, typing isn't the hard part. With slower cycles, I think more about how much to try before submitting work. Some times I feel comfortable pounding out quite a bit of code. Other times, I know there's some subtlety so I need to double check things. I don't want to stumble on forgetting a const declaration, or something silly like that. Iterations are slower, but you can spend time in flow thinking harder about each loop. Although, sometimes, I do just stare at the console waiting for feedback. That's usually a good time to go to the bathroom and maybe grab a snack. Not necessarily multitasking. Just being careful about what plates are spinning, and which I can set down or pick up between steps.
- zozbot234 5y ago> fast cycles are liberating, because it's easy to just ask the compiler or your testing harness if you're doing the right Type checking is still a very quick part of compile, so it can still support a "fast cycle" workflow if most simple errors are detected via incompatible types. You just need to go all-in on type-driven development, rather than simple reliance on unit tests.
- jfoutz 5y agoah, I alluded to that with "ask the compiler". but yeah, types are great. Quickcheck is great too. But you'll have to pry my oracles from my cold dead hands. Computers show me over and over how stupid I am. Yeah, if I have a regression, I'm adding a specific test for that.
- deleted 5y ago[deleted]
- aaaaaaaaaaab 5y agoI just browse HackerNews.
- ModernMech 5y ago> newcomers will stare at compiler output. I know at least for me, I sit in quiet contemplation and think while the project is compiling. I expect the context switch of going between writing docs and writing code on every compile would be too much for my brain. Is it managers making you feel like you need to be doing something else while your code is compiling? I guess I just never felt like I was being unproductive while my code was compiling.
- gambiting 5y agoI work in videogames - making any change to code takes about 2-4 minutes to compile(huge C++ codebase with a billion templates, it actually takes about 40 minutes from scratch with distributed build, few hours without it), plus second that again for the game to start and test. And god forbid you made any changes to data - then it's about 20-30 minutes to binarize the data packs again and deploy them. Really makes you slow down and think any change through before trying it. The "pray and spray" approach to coding simply doesn't work here.
- Kelteseth 5y agoHave you tried ccache now that it has MSVC support?
- gambiting 5y agoWe use clang for all configurations and all platforms, and we use FastBuild(we also used to pay for Incredibuild but it wasn't actually any faster than FastBuild in our testing).
- deaddodo 5y agoI'm actually curious why they bother converting game data at all into binary formats, before production builds. The logic is all there to load the data and you already have the raw data local; I would assume it takes more logic to unpack it and would seem faster to just use the raw data.
- londons_explore 5y agoThe data before packing and the data after unpacking are probably not the same formats. Some of the packing steps are also probably lossy (eg. Take this super high poly count model, and cut away 99% of the polygons). If you skip that culling step, the game probably won't run.
- gambiting 5y agoYes, that's exactly what it is. The "data" might be 8K textures, as part of the binarization it gets converted into a format that the client can understand, but also follows a "recipe" for the texture set throught the editor(so convert it a 2K texture with a specific colour spec). Same for models etc. And yes, the client itself usually can't read the raw data, and even if it could there is not enough ram on consoles to load everything as-is. The workstations we use for development all have 128GB of ram just so you can load the map and all models in-editor.