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

[H. S. Teoh]

On Fri, Nov 12, 2021 at 10:47:56PM +0000, Stanislav Blinov via Digitalmars-d wrote:
> On Friday, 12 November 2021 at 22:10:22 UTC, H. S. Teoh wrote:
> 
> > Life is too short to fuss over code that isn't even relevant to
> > performance in the big picture.
> 
> Life is too short to wait on programs that have no reason to be slow.
> If you're "rendering splash screen while loading resources", you're
> most likely doing something wrong. Your program should've been on
> screen and interactive ages ago. Granted, there can be exceptions
> (like slow storage), but those are very, very rare. Visual Studio has
> no business taking 8 seconds to load just to show its start screen.

If you're waiting 8 full seconds, that's a sign that something is wrong
with your performance. ;-)  Incidentally, this is why I don't bother
with IDEs; most of them are bloated for no reason and take ages to load
"resources" who knows for what. I could already be typing code in Vim
and could already be compiling the first draft by the time they finish
"starting up".  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.  If you're taking 8
seconds to start up, that *is* a performance problem and you should be
optimizing that!


> But it does. In a team of 50 people, starting it up twice a day, it
> wastes 57 man-hours a year. In other words, VS is a worker that comes
> in 7 days a year with full salary and amenities, to do absolutely
> nothing.

I agree, that's why I don't bother with IDEs.  Especially not those that
need to be started up every day.  I mean, who has the time to wait for
that?!  I keep my Vim sessions in GNU Screen for months, if not years,
at a time, and as soon as I sit down at my desk I can continue where I
left off yesterday immediately.


> "The rest of the code that only runs once in a while don't matter" is
> an anachronism that needs to die, with fire. Whether you run once or a
> hundred times, you bloody well should run as fast as you possibly can,
> because there's always someone (or something) waiting on you!
> Including your own CPU. At the very least, it's just irresponsible to
> run unnecessarily slow.

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.

But you took what I said completely out of context. 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.  (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?? It's not the bottleneck, you should be spending
your time fixing actual bottlenecks instead.  That's my point.


> Scripts for your own self - fine, leave 'em as slow as you're willing
> to suffer through. But please don't inflict your sloth-ness on the
> rest of the world ;)

Honestly, just about *anything* written in D runs faster than any shell
script (except perhaps for the most trivial of things like hello world
programs -- actually, even those run faster in D :-P).  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.

And seriously, "ultra-optimized" code wastes more time than it 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.  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*.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.