|
code:
|
# ? Oct 10, 2014 01:42 |
|
|
# ? May 17, 2024 17:22 |
|
Our compile times are in excess of 4 minutes right now. Not because our code is huge, but because the compiler spawns a new process for each C file and waits for each one in a single thread. There's no concurrency at all. As an added bonus every single invocation waits for a license validation before it actually starts. Embedded development!
|
# ? Oct 10, 2014 16:01 |
|
Spatial posted:Our compile times are in excess of 4 minutes right now. Try a couple of hours. For an incremental build. Want to run regression tests? Start the build when you leave, and hope the server that schedules the hardware for online tests doesn't die overnight, as it did yesterday.
|
# ? Oct 10, 2014 16:31 |
|
Zopotantor posted:Try a couple of hours. For an incremental build. I don't think I ever had it that bad, but I did have 30 minutes for incremental and 4 hours for a full build when I did embedded for a box that had a half meg image size. I also had another one that took only 4-5 minutes, but if you touched a certain header file, you might as well go home for the day. Add in the 5+ minutes to flash, and another 5 booting, and well development for embedded can be mighty slow. Now I don't have it so bad since I'm doing Java web services. I take that back do to all the post compile analysis I think my current Java code takes 30 minutes per build on the "official" build server. It takes about a minute locally.
|
# ? Oct 10, 2014 17:18 |
|
HFX posted:I don't think I ever had it that bad, but I did have 30 minutes for incremental and 4 hours for a full build when I did embedded for a box that had a half meg image size. I also had another one that took only 4-5 minutes, but if you touched a certain header file, you might as well go home for the day. Add in the 5+ minutes to flash, and another 5 booting, and well development for embedded can be mighty slow. Oh Java gets up there. Where I work it's just under 4 hours for a build and light test on the server. And that's if there's no waiting to get on to the build engines.
|
# ? Oct 10, 2014 17:31 |
|
carry on then posted:Oh Java gets up there. Where I work it's just under 4 hours for a build and light test on the server. And that's if there's no waiting to get on to the build engines. How do you get Java to build so slow? Did you give the JVM enough memory? Are you downloading things during the build process? I am really curious.
|
# ? Oct 10, 2014 18:01 |
|
To be clear, it's a very large piece of enterprise software. I honestly don't think the "build the product" stage is that long, but with testing it can take quite a while.
|
# ? Oct 10, 2014 18:34 |
|
Apparently unsupervised machine learning is a totally valid strategy for data with a small number of well-defined, discrete, unambiguous categories. Because of this I apparently don't need labeled training data at all! I can just try to say whether a piece of data goes in category A, B, C, D, or E based on what cluster it falls in, because clustering is definitely made for that purpose. Yep.
|
# ? Oct 10, 2014 19:05 |
|
it is posted:Apparently unsupervised machine learning is a totally valid strategy for data with a small number of well-defined, discrete, unambiguous categories. Because of this I apparently don't need labeled training data at all! I can just try to say whether a piece of data goes in category A, B, C, D, or E based on what cluster it falls in, because clustering is definitely made for that purpose. Yep. Are they intentionally censoring the categories or something?
|
# ? Oct 10, 2014 19:32 |
|
carry on then posted:To be clear, it's a very large piece of enterprise software. I honestly don't think the "build the product" stage is that long, but with testing it can take quite a while. Our product takes about 2.5 hours to build. A complete suite of tests adds around two weeks to that.
|
# ? Oct 10, 2014 19:40 |
|
qntm posted:Our product takes about 2.5 hours to build. A complete suite of tests adds around two weeks to that. What kind of product is it? Without revealing personal information.
|
# ? Oct 10, 2014 19:48 |
|
fritz posted:Are they intentionally censoring the categories or something? Well I mean the problem is a little bit uncommon of one to work on so I'm doing the censoring myself, mostly as a way to anonymize me. Pretend that I'm trying to determine whether you're gonna vote Republican, Democrat, or 3rd party. I have all sorts of demographic information on you and I'm splitting all the information into clusters and I'm saying "yep this sure looks like a whole bunch of Republicans" rather than actually asking anybody what party they voted for. it is fucked around with this message at 20:12 on Oct 10, 2014 |
# ? Oct 10, 2014 20:04 |
|
carry on then posted:What kind of product is it? Without revealing personal information. Heavyweight enterprise software.
|
# ? Oct 10, 2014 21:08 |
|
qntm posted:Our product takes about 2.5 hours to build. A complete suite of tests adds around two weeks to that. What the f is a suite of tests good for if it takes 2 weeks to run?
|
# ? Oct 10, 2014 21:46 |
|
It's the Deluxe Executive Suite.
|
# ? Oct 10, 2014 21:49 |
|
Back when I worked in games sometimes it would take the PS2 builds around 40 minutes to complete. Most of that was because of lovely pipeline for static binaries though.
|
# ? Oct 10, 2014 22:08 |
|
pigdog posted:What the f is a suite of tests good for if it takes 2 weeks to run? The immediate post-build verification test that we run on every single build is a few minutes. When I say "suite" I mean our entire regression test suite, which is about 30,000 distinct test cases (I think) divided into a few hundred different smaller suites all testing different functionality. If you've only modified a smaller area of the software then running the whole suite isn't necessary, you'll queue up only the tests you care about. It is a problem though. The majority of the test suites are very old (written more than five years ago) and almost none of them were built with parallelisation in mind (i.e. running multiple tests simultaneously on the same machine). Also there are pretty time-consuming setup and teardown phases for almost every test. We have a lot of test machines, which improves things, but the number of distinct platforms (~12) we need to test on brings the time back up again. We're trying to get it down to one day for the whole thing.
|
# ? Oct 10, 2014 22:23 |
|
Well, okay, but that's still way too long for the tests to be even useful. What's the point of running them and concluding that hey, the code from 2 weeks ago is not working? I see you're aware of the problem, but at that stage, besides optimizations and parallelization, you might take a good look at those tests and maybe straight up delete 80% of the slower and less useful ones. It's something that people actually do, besides using 100's of cloud servers for test running.
|
# ? Oct 10, 2014 22:45 |
|
pigdog posted:Well, okay, but that's still way too long for the tests to be even useful. What's the point of running them and concluding that hey, the code from 2 weeks ago is not working? I see you're aware of the problem, but at that stage, besides optimizations and parallelization, you might take a good look at those tests and maybe straight up delete 80% of the slower and less useful ones. It's something that people actually do, besides using 100's of cloud servers for test running. Full regression tests to go live can easily take 2+ weeks especially depending on your data. Remember, you are testing both unit, integration, stability, and performance tests.
|
# ? Oct 11, 2014 00:03 |
|
Yeah, it's important to remember that while these massive builds are taking place, developers are constantly running personal builds that run only the unit/feature tests. Then, once the first full build that includes various change sets completes (and fails,) possible causes are identified and backed out. At least that's how we do it, although our full builds aren't nearly that long. e: and even if development is done on certain features there's still user testing being conducted at the same time.
|
# ? Oct 11, 2014 00:08 |
|
Spatial posted:Our compile times are in excess of 4 minutes right now. Not because our code is huge, but because the compiler spawns a new process for each C file and waits for each one in a single thread. There's no concurrency at all. As an added bonus every single invocation waits for a license validation before it actually starts. Common SunCC problem, workaround is to slurp in all the C files in one compile. OpenBSD tries to do this for everything in ports.
|
# ? Oct 11, 2014 00:33 |
|
Boy, that's a nice compiled version of that tool there. Yeah, the one we use in the build. You checked it into version control? Of course, wouldn't want to have to compile a single small utility once per clean build. Oh, what's this? It's linked against a version of a DLL that only comes with an older compiler suite, so it's missing if you built a fresh machine with the newest tools? And the batch file that calls it doesn't check error codes? No, no problem, I didn't plan to get anything done this afternoon anyway. (Hmm! I wonder why there are 4 copies of that DLL checked into different parts of the tree...)
|
# ? Oct 11, 2014 01:03 |
|
MrMoo posted:Common SunCC problem, workaround is to slurp in all the C files in one compile. One of the projects here at this company, the guy who wrote the makefile did this sort of, and worse. Like to build the main library, it was originally code:
code:
Most of that stuff I managed to fix, then we put the project on ice, then that guy quit.
|
# ? Oct 11, 2014 02:36 |
|
at my old company we used bespoke recursive Makefiles. everything was also built in the tree so builds would be reused even if they used different compiler arguments. plug in a suitable number for -j and you're good, right? we ran into a fun afternoon problem where a particular build was setting a different sets of flags, and depending on the ordering it would either build fine or crash. since nobody edited that code it was decided we'd just c/p the code into two directories - one for flags and one without. never again.
|
# ? Oct 11, 2014 03:22 |
Subjunctive posted:(Hmm! I wonder why there are 4 copies of that DLL checked into different parts of the tree...) Pfft I can't be bothered to exclude bin and obj folders from my svn. Commit all baby!
|
|
# ? Oct 11, 2014 04:24 |
|
Manslaughter posted:Pfft I can't be bothered to exclude bin and obj folders from my svn. Commit all baby! No, it was on purpose, because others had hit the problem with other tools and just brute-forced it. La la la. FamDav posted:at my old company we used bespoke recursive Makefiles. everything was also built in the tree so builds would be reused even if they used different compiler arguments. plug in a suitable number for -j and you're good, right? Did you work at Netscape?
|
# ? Oct 11, 2014 04:39 |
|
I've developed a fetish for compiling gcc.
|
# ? Oct 11, 2014 04:56 |
|
Voted Worst Mom posted:I've developed a fetish for compiling gcc. In the event of a compilation lasting more than 4 hours, seek immediate medical help to avoid long-term injury.
|
# ? Oct 11, 2014 05:22 |
|
Subjunctive posted:No, it was on purpose, because others had hit the problem with other tools and just brute-forced it. La la la. nope but i worked on software mostly built by academics in the early 2000s
|
# ? Oct 11, 2014 05:36 |
|
|
# ? Oct 11, 2014 10:58 |
|
That's certainly a code smell of some kind...
|
# ? Oct 11, 2014 14:05 |
|
MrMoo posted:Common SunCC problem, workaround is to slurp in all the C files in one compile. It's literally the only supported way to compile sqlite, and the process to make the single C file involves several scripts written in loving tcl. It was great fun trying to compile a sqlite fork (sqlcipher) for iOS
|
# ? Oct 11, 2014 15:43 |
|
hackbunny posted:It's literally the only supported way to compile sqlite, and the process to make the single C file involves several scripts written in loving tcl. It was great fun trying to compile a sqlite fork (sqlcipher) for iOS Like y'all have never heard of unity builds Modules can't come quickly enough
|
# ? Oct 11, 2014 18:34 |
|
hackbunny posted:sqlite
|
# ? Oct 11, 2014 18:47 |
|
I'm one of the devs of a fairly complicated JavaScript library that's marketed towards people who used to use mainly Flash. As in, the people using the API might not have a lot of experience with programming. Anyway, for the past month or so there has been a big push to create an extensive documentation portal for the product, including a JavaDoc-like API reference. I haven't been involved much in that project since whatever, but they finally sent us the final version of the documentation to look over, in preparation for the launch next week. Naturally even the final version includes copious amounts of misinformation, typos, weird formatting, and so on, but my favorite part has to be that methods are listed out like this: GETINFOABOUTTHING() - Method the real method of course being getInfoAboutThing.
|
# ? Oct 12, 2014 07:55 |
|
The best documentation is:code:
|
# ? Oct 12, 2014 08:33 |
|
Suspicious Dish posted:The best documentation is: You'd love working on our codebase. You wouldn't.
|
# ? Oct 12, 2014 08:44 |
|
Suspicious Dish posted:The best documentation is: One time I had a change rejected because I didn't add giant comment blocks on getters/setters I introduced, when I resubmitted with php-doc generated comments I was chastised for not being descriptive enough.
|
# ? Oct 12, 2014 09:05 |
|
Suspicious Dish posted:The best documentation is: Honestly I never know what to do with functions like that, that is, functions that do fairly obvious things. A well-named function and set of parameters should be fairly self-documenting, but I always feel like it's better to have stupid, obvious function header comments than none at all. If for no other reason than that the color of the comment text is a better visual separator than anything else. I see that big block of green, I know I'm at the start of a function no matter how fast I'm scrolling.
|
# ? Oct 12, 2014 12:30 |
|
|
# ? May 17, 2024 17:22 |
|
I like how IDEs will happily poo poo out pointless boilerplate commentary then save it in the text of the file. Why not just generate it and show it to me, but leave my suffering colleagues alone unless I actually put some thought into the comments and change them.
|
# ? Oct 12, 2014 12:55 |