[Feature Request] Add Option to Bypass `StackTrace.current` on Statement Execution

[gmpassos]

First of all, thank you for the great work on this package — it's been very helpful in our projects!

I'm using postgres: ^3.5.6 on Dart 3.8.1, and noticed that every statement execution, even when successful, calls StackTrace.current. While this is useful for error reporting, it's not a cheap operation in the Dart VM.

In my benchmarks, this call alone is responsible for about 3% of total CPU usage, which adds up significantly in high-throughput scenarios.

Would it be possible to:

• Add an option to disable stack trace capturing, or
• Use a constant/dummy trace (e.g., StackTrace.empty) when needed?

This would help reduce unnecessary overhead in production environments where the stack trace isn’t needed on every successful execution.

In my case, the default backend StackTrace already provides the necessary information when an execution error occurs.

Thanks again!
Best regards.

[isoos]

@gmpassos: an interesting recognition, and it may be worth to investigate it more. Would you be able to create a benchmark that could be run as part of the development of the package (may not be part of the test suite) that measures this?

An option to disable it may work, but it would also introduce some complexity, so first I'd rather check where and how we could measure it and if there is a way around it.

[gmpassos]

My current Dart Dev Tools - CPU Profiler:

This is from a real-world project with a real database snapshot.

[gmpassos]

Here's a more detailed CPU Profiler snapshot:

[gmpassos]

Note that we were using postgres v2.6.3, and after migrating to postgres 3.5.6, I noticed an increase in backend process CPU usage.

Then, after adding some prepared Statement caching, I found that the current bottleneck is actually StackTrace.current.

[gmpassos]

Main calls while executing a query:

postgresql-dart/lib/src/v3/connection.dart

Line 87 in f79e5f8

final trace = StackTrace.current;

postgresql-dart/lib/src/v3/connection.dart

Line 187 in f79e5f8

final trace = Trace.current();

postgresql-dart/lib/src/v3/connection.dart

Line 764 in f79e5f8

_callerTrace = Trace.current() {

postgresql-dart/lib/src/v3/connection.dart

Line 803 in f79e5f8

_callerTrace = Trace.current() {

[gmpassos]

Note that this call to _sendAndWaitForQuery could receive the already captured stack trace: final trace = Trace.current();

postgresql-dart/lib/src/v3/connection.dart

Line 195 in f79e5f8

await _sendAndWaitForQuery<ParseCompleteMessage>(ParseMessage(

This could be a simple fix/optimization for the current version.

[gmpassos]

FYI @isoos

A PR with a simple optimization:

#432

[isoos]

I'm not convinced that StackTrace.current is really the blocking part. As a sanity check:

  final sw = Stopwatch()..start();
  for (var i = 1000000; i>0;i--) {
    StackTrace.current;
  }
  sw.stop();
  print(sw.elapsedMicroseconds);

This is giving me about 0.5 microsecond / trace, which, given the roundtrip latency of a query to/from the postgres server should be negligible. I would need benchmarks that I can run on my machine, which show a measurable difference if I turn on / off the stacktrace capture. On why the profiler shows it as significant, I'm not sure, maybe an artifact of profiling.

There are many differences between the old and the new version, and there may be more async operations where the efficiency (and wall-clock latency) would be impacted, but the total CPU compute required for one request did not change that much.

This change, as I see it, would complicate the API, without much evidence of the improvement. Having said that, if you have a benchmark that I can run, debug, and it shows the difference, I'll look into it further.

[gmpassos]

In your benchmark, the code is being called from the same line each time, so there’s no variation in the resulting stack trace.

Additionally, the stack trace is quite short and straightforward, with no asynchronous calls involved.

In my benchmarks, based on a real-world scenario, this was the main bottleneck — the top method in terms of self time consumption.

As a general note, capturing a StackTrace is known to be an expensive operation and is best avoided when possible. In fact, calling StackTrace.current repeatedly, outside of special use cases such as error handling or debugging, is generally considered poor coding practice due to its performance impact.

[gmpassos]

FYI:

dart-lang/sdk#40130

[isoos]

Future<void> main() async {
  final sw = Stopwatch()..start();
  for (var i = 1000000; i > 0; i--) {
    calc(100 + i % 10);
  }
  sw.stop();
  print(sw.elapsedMicroseconds);
}

void calc(int depth) {
  if (depth > 0) {
    calc(depth - 1);
  } else {
    StackTrace.current;
  }
}

This gives me ~3 microseconds / trace, with a depth of 100 calls. The stack trace is not cached, because 10x iteration will result about 10x execution time.

I'm happy to take reasonable benchmark, but right now, I'm not convinced that this is a real issue here. There may be something that pushes the stacktrace.current to be present in the captured frames, but I'm not convinced it is the trace itself. Have you tried modifying the package with empty stack traces and measuring it that way? Also: sampling profiler (which I presume is used here) has its limits, it may be better to just measure wall-clock time latencies.

[gmpassos]

Future<void> main() async {
  final sw = Stopwatch()..start();
  for (var i = 1000000; i > 0; i--) {
    calc(100 + i % 10);
  }
  sw.stop();
  print(sw.elapsedMicroseconds);
}

void calc(int depth) {
  if (depth > 0) {
    calc(depth - 1);
  } else {
    StackTrace.current;
  }
}

This gives me ~3 microseconds / trace, with a depth of 100 calls. The stack trace is not cached, because 10x iteration will result about 10x execution time.

I'm happy to take reasonable benchmark, but right now, I'm not convinced that this is a real issue here. There may be something that pushes the stacktrace.current to be present in the captured frames, but I'm not convinced it is the trace itself. Have you tried modifying the package with empty stack traces and measuring it that way? Also: sampling profiler (which I presume is used here) has its limits, it may be better to just measure wall-clock time latencies.

---

This is definitely an issue. StackTrace.current now accounts for 20–30% of the CPU time during query execution and causes unnecessary memory allocations (real-world case).

The PR I submitted reduces calls to StackTrace.current without changing behavior or adding new features.
Please consider merging it — I’d really appreciate it!

#432

Best regards.

[isoos]

StackTrace.current now accounts for 20–30% of the CPU time during query execution and causes unnecessary memory allocations (real-world case).

This is a huge claim, especially upshooting from the 2-3% from the previous claim on the profiler screenshot, which would be still large to be honest. However, it does not match my experience, not just the micro-benchmark above, but at other applications. Please, let's create a benchmark that could show your claim.

[gmpassos]

StackTrace.current now accounts for 20–30% of the CPU time during query execution and causes unnecessary memory allocations (real-world case).

This is a huge claim, especially upshooting from the 2-3% from the previous claim on the profiler screenshot, which would be still large to be honest. However, it does not match my experience, not just the micro-benchmark above, but at other applications. Please, let's create a benchmark that could show your claim.

I said 2–3% of the total CPU time. It's not acceptable for StackTrace.current alone to be responsible for that. This is a clear example of a bottleneck. Of all the things the backend is handling, StackTrace.current dominates CPU time (yes, a single call consuming nearly 1% is a bottleneck), whereas it actually shouldn’t be a noticeable factor.

Note that your microbenchmark is very different from real-world backend conditions.

[isoos]

I've created this simple benchmark test:

import 'package:postgres/postgres.dart';
import 'package:test/test.dart';

import 'docker.dart';

void main() {
  withPostgresServer('Benchmarking queries', (server) {
    late Connection connection;

    setUp(() async {
      connection = await server.newConnection();
    });

    tearDown(() async {
      await connection.close();
    });

    test('simple query', () async {
      final sw = Stopwatch()..start();
      for (var i = 10000; i > 0; i--) {
        await connection.execute('SELECT 1');
      }
      sw.stop();
      print(sw.elapsedMicroseconds);
    });
  });
}

The test shows an execution time of 25.5-26 seconds on my notebook (there is a varying because of the network access and random OS processes). I'm changing all of the [Stack]Trace.current calls to empty in connection.dart, and re-run the benchmark, and it is still in the 25.5-26 seconds range. If there were a 2% difference, it should be in the 25-25.5 range, but it isn't.

Again: I'm willing to consider this, if there is a good benchmark that shows that it is a problem. Sampling profiling is not indicative of the actual CPU profile, it can have weird artifacts (at least on Java it had, not sure about Dart, but wouldn't surprise me).