Range has a funny constructor

[davidhesselbom]

    new: static func (.min, .max) -> This {
        this : This
        this min = min
        this max = max
        return this
    }

I can think of reasons why Range doesn't have a normal (init) constructor:

• it was written at a time when covers didn't have constructors
• it's old, but it works, so no one has bothered to change it
• it's so low level and so deep inside the SDK, or used in rock somewhere constructors can't be used

Are there other reasons?

[horasal]

It was introduced in https://github.com/fasterthanlime/rock/commit/4f6d871407e2e683b023e464b0b395780d34a796 (Jan 25, 2010) Other codes at that time use init.

Maybe the compiler uses Range new to unwrap a..b and the compiler was not smart enough to start more rounds to resolve init to new at 2010, I guess ?

[fasterthanlime]

it was written at a time when covers didn't have constructors

this

Other codes at that time use init.

yes, but not covers afaik?

[davidhesselbom]

Okay, so if I make a PR where I change it to

    init: func@ (=min, =max)

, you won't mind?

[fasterthanlime]

@davidhesselbom if it works, I'd be all for it! It's cleaner.

However, in the generate code, that means one more call + pointer dereferences.

The current code generates this:

struct Range Range_new(int min, max) {
  struct Range r;
  r.min = 0;
  r.min = 24;
  return r;
}

Your proposed change will generate this:

struct Range Range_new(int min, int max) {
  struct Range r;
  Range_init(&r, int, min)
  return r;
}

void Range_init(struct Range *range, int min, int max) {
  range->min = min;
  range->max = max;
}

Nothing a good compiler can't optimize, perhaps I used to think Range was performance-critical. Not sure.

Having new directly as a static func is perfectly valid ooc, definitely less funky than trying to cull the GC off of the sdk :)

[davidhesselbom]

Okay, I didn't mean to suggest it's invalid or anything, it's just... longer, and a bit unusual. I hadn't thought about performance, but otoh, I seem to remember you saying someting along the lines of "ooc wasn't designed for speed", and like you, I doubt the change proposed will have any significant effect.

About the GC, ripping it out wasn't my idea, I swear.

[fasterthanlime]

@davidhesselbom once upon a time I was pretty happy that ooc had "the speed of raw C", but that was before String became a class, before many other changes...

Back then I also had a very bad instinct on what did and did not matter performance-wise. As the generated code grew in complexity, it became harder and harder to get useful info out of profilers like cachegrind.

Anyway, as far as performance goes, instincts lie, measure all the things! :8ball:

[davidhesselbom]

as far as performance goes, instincts lie, measure all the things!

True...

[refi64]

ooc needs help speed-wise. Once when I wrote a BF interpreter in ooc, it was slower than Julia, PyPy, and gasp JavaScript...

[fasterthanlime]

ooc generics are slow

ftfy