Live data from Hacker News

Make Ubuntu packages 90% faster by rebuilding them

gist.github.com

171–180 of 375 posts

Re: Make Ubuntu packages 90% faster by rebuilding them

#171
post #167

what makes me jealous,is not the double performance ,but the fact that he can handle 13000 files in 2 seconds. i am at my ${corporate} job now, and have about 40'000 json files stored locally on the windows laptop. when I need to load a them, it takes minutes . i am still not sure if i read files wrong or NTFS is a pile of trash when comes to reading many smallish files

Try excluding that directory from the virus scanner. Also a dev drive might come in handy for this workload

Re: Make Ubuntu packages 90% faster by rebuilding them

#172
post #167

what makes me jealous,is not the double performance ,but the fact that he can handle 13000 files in 2 seconds. i am at my ${corporate} job now, and have about 40'000 json files stored locally on the windows laptop. when I need to load a them, it takes minutes . i am still not sure if i read files wrong or NTFS is a pile of trash when comes to reading many smallish files

NTFS is definitely very slow when it comes to reading many small files. Windows Defender or whatever antivirus you might be using can also further slow this down.

Re: Make Ubuntu packages 90% faster by rebuilding them

#173
post #118

Earlier quoted context omitted.

Debug symbols do not need to be paged in so shouldn’t make much/any difference. Compiling with -O3 can increase code size a lot due to inlining, which can be a little bad.

Right, my humor there was that I'm assuming people specifically did non-debug flags for the build as an optimization. Only for them to still fall short. And understood a little on -O3 possibly increasing code size. I had thought that was more of a concern for tight environments than for most systems? Of course, I'd have assumed that -march=native would be more impactful, but the post indicates otherwise. I said in a…

> Right, my humor there was that I'm assuming people specifically did non-debug flags for the build as an optimization.

It used to be the case that the presence of debug symbols would affect GCC code generation. Nowadays that should be fixed. I think it still affects the speed of compilation so if you're building the whole system from source you might want to avoid it.

Re: Make Ubuntu packages 90% faster by rebuilding them

#174

Earlier quoted context omitted.

Mimalloc is a general purpose allocator like JEMalloc / TCMalloc. Glibc is known to have a pretty bad allocator that modern allocators like MIMalloc & the latest TCMalloc (not the one available by default in Ubuntu) run laps around. While of course speedup may be variable, generally the benchmarks show an across the board speedup (whether that matters for any given application is something entirely different). As for…

Agree for most short running apps. I updated my comment to reflect issues with apps that are constantly reallocating, and running for longer that 60 seconds. But you are absolutely correct for most short running apps, 99% recommended to replace glibc. However, there is an app or two where glibc stability doesnt trigger a pathological use cases, and you have no choice. Hence why its the default, since there are less c…

Funny, cause the situations where I've had to replace glibc is always that it is a long running server that allocates often. Glibc: Ballooning memory, eventually crash. jemalloc: Stable as a rock.

Re: Make Ubuntu packages 90% faster by rebuilding them

#175

Engineering is a compromise. The article shows most gains come from specialising the memory allocater. The thing to remember is that some projects are multithreaded, and allocate in one thread, use data in another and maybe deallocate in a 3rd. The allocator needs to handle this. So a speedup for one project may be a crash in another. Also, what about reallocation strategy? Some programs preallocate and never touch m…

That’s why it’s a bad idea to use one allocator for everything in existence . It’s terrible that everyone pays the cost of thread safety even for single threaded applications - or even multithreaded applications with disciplined resource management.

While I do agree with the general sentiment, I think the default should be to use the safer ones that can handle multi threaded usage. If someone wants to use a bad allocator like glibc that doesn't handle concurrency well, then they should certainly be free to switch.

Re: Make Ubuntu packages 90% faster by rebuilding them

#176
post #120

Earlier quoted context omitted.

What would that even mean?

Portage on top of Fuchsia, probably. There's not all that much more to Gentoo all things considered.

Zircon is miles apart from linux. It’s like saying you’d run Portage on top of Windows. You and what army?

Re: Make Ubuntu packages 90% faster by rebuilding them

#177
post #167

what makes me jealous,is not the double performance ,but the fact that he can handle 13000 files in 2 seconds. i am at my ${corporate} job now, and have about 40'000 json files stored locally on the windows laptop. when I need to load a them, it takes minutes . i am still not sure if i read files wrong or NTFS is a pile of trash when comes to reading many smallish files

NTFS is slow, especially when you operate on a lot of tiny files (nobody in the Windows world would do that, you'd always put your tiny data blobs into a bigger container file, e.g. asset files in games), but from my corporate experience, it's mostly the _multiple_ "endpoint security" solutions that bog file system performance down.

It's the reason I so far use a Mac at work, which has its own issues, and a lot of them.

Re: Make Ubuntu packages 90% faster by rebuilding them

#178
post #57

Gentoo linux is essentially made specifically for people like this, to be able to optimize one’s own linux rig for one’s specific usecase. After initial setup, it’s pretty simple and easy to use, I remember making a ton of friends at matrix’s Gentoo Linux channel, was fun times. https://www.gentoo.org/ Fun fact, initial ChromeOS was basically just custom Gentoo Linux install, I’m not sure if they still use Gentoo Lin…

I used Gentoo for a while, but the temptation to endlessly fiddle with everything always let me to eventually break the system. (It's not Gentoo's fault, it's mine.) Afterwards I moved to ArchLinux, and that has been mostly fine for me. If you are using a fairly standard processor, then Gentoo shouldn't give you that much of an advantage?

I've broken Arch but never broken Gentoo. I think this more due to the fact I ran Arch first and you then Gentoo first, rather than any real difference between them.

Gentoo is more stable than Arch by default, though. It's not actually a bleeding edge distro, but you can choose to run it that way if you wish. Gentoo is about choice.

Re: Make Ubuntu packages 90% faster by rebuilding them

#180

Earlier quoted context omitted.

I assume people downvoted it because “ASLR obscures the memory layout. That is security by obscurity by definition” is just wrong (correct description here: https://news.ycombinator.com/item?id=43408039 ). It does say [flagged] too, though, so maybe that’s not the whole story…?

No, that other definition is the incorrect one. Security by obscurity does not require that the attacker is ignorant of the fact you're using it. Say I have an IPv6 network with no firewall, simply relying on the difficulty of scanning the address space. I think that people would agree that I'm using security by obscurity, even if the attacker somehow found out I was doing this. The correct definition is simply "usin…

In the limit, an encryption key falls to the same logic. You simply rely on the difficulty of scanning all possibly keys.
Post reply on HN