Challenge: write a reference counted slice that works as much as possible like a built-in slice

Stanislav Blinov stanislav.blinov at gmail.com
Sat Nov 13 03:00:54 UTC 2021


On Saturday, 13 November 2021 at 01:12:32 UTC, H. S. Teoh wrote:

> That's not what I was talking about, though.  I was talking 
> about programs that load in 1 second or less -- in which case 
> trying to optimize startup code is a waste of time.

It isn't. One second is four billion cycles. Or eight, sixteen, 
thirty two... if you're actually running multi-core. 60 full 
frames of smooth animation. Or gigabytes and gigabytes of data 
transferred. If you're not up and running in under a dozen 
milliseconds (i.e. one frame), you're slow. And if you are, you 
don't need any silly splash screens.

> If you're taking 8 seconds to start up, that *is* a performance 
> problem and you should be optimizing that!

Yeah, tell that to Microsoft ;) To them, 10s is fine. And they're 
not exactly outliers. Photoshop, Gimp, Krita, Maya, 3D Max, 
literally any video editor... Browsers, don't get me started on 
those.
This very web service takes like 5 full seconds to post a 
message. There was a time when 5 seconds wasted time online was A 
LOT.

> Given that I run my Vim sessions for years at a time, startup 
> time *is* completely irrelevant to me. :-D  If your program is 
> such that people have to constantly restart it, something is 
> bogonous with your design and you *should* consider scrapping 
> it and doing it better.

There may be other reasons for restarting. Such as voluntary or 
mandatory breaks, security regulations. If something is 
irrelevant to you does not necessarily mean it's irrelevant to 
the next guy.
Bottom line is, there's very little software that actually *has* 
to start slow. And the majority of what does start slow today 
isn't that.

> But you took what I said completely out of context.

I don't think I have.

> I was talking about optimizing the code where the profiler 
> indicates an actual bottleneck; 90% of your code is not part of 
> a bottleneck and therefore "optimizing" it prematurely is a 
> waste of time, not to mention it makes for needlessly 
> unreadable and unmaintainable code.

You don't optimize prematurely. It's often enough to just not 
pessimize for no reason. Using a fixed-size array or a 
static_vector instead of dynamic one here. Using a table instead 
of a bunch of math there. Or vice versa, depending. Doing a 
simple cursory assessment for a possibly better algorithm. Making 
one syscall instead of two. Something as trivial as aligning your 
data. Do you really need this ".array" call here, or can you do 
with a ".copy" into existing storage? Maybe layout your array 
differently and let multiple threads at it?..

> (An 8-second startup time *is* a bottleneck, BTW. Just so we're 
> on the same page.)  If code that isn't part of a bottleneck is 
> allocating and waiting for GC collection, who cares??

??? Everybody that comes after you cares! If Atila can make his 
thing run in 1µs, but *chose* to leave it at 1ms, because *to 
him*, anything slower than 20ms doesn't count as slow, he just 
flat out denied 999µs to someone else. Which can be centuries to 
that someone. There is no good reason not to do everything you 
can to stop your code from being slow. To get your data out that 
much sooner. To let the CPU go that much sooner. Either for other 
processes, or so that it can go to sleep and save that power.

> It's not the bottleneck, you should be spending your time 
> fixing actual bottlenecks instead.  That's my point.

Of course you should. But that doesn't mean that everywhere else 
you should be lazy. If it doesn't matter to you, be sure it does 
to someone who executes after you. Or someone who's sitting in 
front of the screen, or on the other end of the wire across the 
world. Or heck, to yourself: whether you'll have enough juice to 
make that important phone call on the weekend.

> Just the very act of writing it in D has already given me a 
> major speed boost, I'm not gonna sweat over squeezing 
> microseconds out of it unless I'm also planning to run it in a 
> tight loop 1,000,000 times per second.

Why not? Why wouldn't you? Ain't gettin' paid for that? I mean, 
it's a reason. Not a very good one, IMO, but a reason. But if not 
that, then what?

> And seriously, "ultra-optimized" code wastes more time than it

I'm not talking about "ultra-optimized" code.

> saves, because it makes code unreadable and unmaintainable, and 
> the poor fool who inherits your code will be wasting so much 
> more time trying to understand just what the heck your code is 
> trying to do than if you had written it in an obvious way 
> that's slightly slower but doesn't really matter anyway because 
> it's not even part of any bottleneck.

It does matter. Why do you keep insisting that it doesn't? It 
does. Just because it's not a bottleneck doesn't mean it's fine 
to just let it be slow. It's wasted cycles. No, you shouldn't 
necessarily "ultra-optimize" it. But neither you should just sign 
off on a sloppy work.

> All those hours added up is a lot of wasted programmer wages 
> which could have been spent actually adding business value, 
> like y'know implementing features and fixing bugs instead of 
> pulling out your hair trying to understand just what the code 
> is doing.
>
> Do the rest of the world a favor by keeping such unreadable 
> code out of your codebase except where it's actually 
> *necessary*.

No disagreements here.




More information about the Digitalmars-d mailing list