Consult - The difference between `is` and `==`

[l-7-l]

i mean study... 👀

why is faster than compare string

action is AddItemAction is faster than comparing Strings!

[brianegan]

Hrm, I'm not sure what the compiler is doing internally to make it faster, but running benchmarks comparing the two, using is was quite a bit faster (4-5x faster) both in Web environments and for Flutter apps (running in profile mode).

I'd have to inspect the bytecode to see why that's the case, but I couldn't tell ya off the top of my head! You can always run your own benchmarks to compare these as well to ensure this statement is accurate by using the official benchmark harness: https://pub.dartlang.org/packages/benchmark_harness

To be fair, I don't think you'll run into many performance bottlenecks with either approach, but I still like how is property casts the type for ya as well.

[l-7-l]

@brianegan cool

[l-7-l]

thank you

there is a test

import 'package:benchmark_harness/benchmark_harness.dart';


void main() => TemplateBenchmark.main();

class A {
  String item;
}

class B {
  String item;
}
// Create a new benchmark by extending BenchmarkBase
class TemplateBenchmark extends BenchmarkBase {
  const TemplateBenchmark() : super("Template");

  static void main() {
    new TemplateBenchmark().report();
  }

  // The benchmark code.
  void run() {
    A is B;
  }

  // Not measured setup code executed prior to the benchmark runs.
  void setup() {
    print('Before the bechmarks run `is`');
  }

  // Not measures teardown code executed after the benchark runs.
  void teardown() {
    print('After the bechmarks run');
  }
}


// A is B
// 0.10655281143588705 us.
// A == B;
// 0.11805417907662034 us.

[brianegan]

Hey there -- not exactly sure how the string test is working, but rather than comparing A == B (which will compare if the two instances are the same) you want to compare A.item == B.item (which calls the == method for the String class). In Redux.js, the "Flux Standard Actions", you provide a type string for comparison. This might be a test closer to reality, with an action named I've used in projects:

import 'package:benchmark_harness/benchmark_harness.dart';

void main() {
  IsBenchmark.main();
  StringBenchmark.main();
}

class StartSearchAction {
  final String type = 'StartSearchAction';

  const StartSearchAction();
}

class B {}

// Create a new benchmark by extending BenchmarkBase
class IsBenchmark extends BenchmarkBase {
  final a = const StartSearchAction();

  const IsBenchmark() : super("IsBenchmark");

  static void main() {
    new IsBenchmark().report();
  }

  // The benchmark code.
  void run() {
    a is StartSearchAction;
  }

  // Not measured setup code executed prior to the benchmark runs.
  void setup() {
    print('Before the bechmarks run `is`');
  }

  // Not measures teardown code executed after the benchark runs.
  void teardown() {
    print('After the bechmarks run');
  }
}

// Create a new benchmark by extending BenchmarkBase
class StringBenchmark extends BenchmarkBase {
  final a = const StartSearchAction();

  const StringBenchmark() : super("StringBenchmark");

  static void main() {
    new StringBenchmark().report();
  }

  // The benchmark code.
  void run() {
    a.type == 'StartSearchAction';
  }

  // Not measured setup code executed prior to the benchmark runs.
  void setup() {
    print('Before the == benchmark');
  }

  // Not measures teardown code executed after the benchark runs.
  void teardown() {
    print('After the == benchmark');
  }
}

// flutter: Before the bechmarks run `is`
// flutter: After the bechmarks run
// flutter: IsBenchmark(RunTime): 0.0837241156430975 us.
// flutter: Before the == benchmark
// flutter: After the == benchmark
// flutter: StringBenchmark(RunTime): 0.12131381159564723 us.

Looks like the String comparison was a bit faster than the last time I checked, but still slower than an is check, and becomes slower as the string becomes longer. So yah, either way -- both of these operations are very quick, and you can perform thousands of these checks per
microsecond. Since we generally want our UIs to perform at 60-120fps, let's assume we have 8ms per frame. Even if you were running all of your reducer is or a.type == 'Hello' checks, you should be able to perform thousands of these checks without hurting performance too much.

Overall, I'd still recommend is checks. Strings can be accidentally duplicated in a codebase, and Types are unique. In addition, the casting is provides is quite handy. Even better: I think using the TypedReducer classes might provide the best readability, but that's just my opinion.