davidbarsky

     574ms handle_completion
        28ms CompletionContext::new
          14ms CompletionContext::analyze
            14ms Semantics::analyze_impl (2 calls)
             0ms SourceBinder::to_module_def (2 calls)
             0ms body_with_source_map_query
               0ms crate_def_map:wait (5 calls)
             0ms crate_def_map:wait (6 calls)
             0ms generic_params_query (2 calls)
            14ms infer:wait @ detail = "new"  (2 calls)

davidbarsky

<details>
    <summary> </summary>

```
    783ms handle_completion
        30ms CompletionContext::new
          13ms CompletionContext::analyze
            13ms Semantics::analyze_impl (2 calls)
            13ms infer:wait @ detail = "new"  (2 calls)
              13ms infer_query

davidbarsky

#![deny(rust_2018_idioms)]
/// This is a example showing how information is scoped with tokio's
/// `task::spawn`.
///
/// You can run this example by running the following command in a terminal
///
/// ```
/// cargo run --example tokio-spawny-thing
/// ```
use futures::stream::{FuturesUnordered, StreamExt};

davidbarsky

Items:

1. Better usage docs/examples. The invocation context is accessible through the INVOCATION_CTX task-local which should be documented in examples and documenation. https://github.com/awslabs/aws-lambda-rust-runtime/blob/master/lambda/src/lib.rs#L95-L97. Note that due to limitations in Tokio's task local implementation, subtasks of the invocation task (which is what we run for customers) can't access this task-local. This is a tempoary limitation.
2. Use tracing for internal logging/instrumentation. Each interaction with the Runtime APIs should be a debug_span! and spawning a new task should a debug_span!. davidbarky@ should handle this.
3. Slightly refactor the simulated endpoint logic to be driven by an Rng rather than a hard-coded UUID.
   1. We should add an init_failure simulated endpoint and propogate tasks out.
   2. The path routing logic can be cleaned up a bit more by using recently-stabilized Rust features.

davidbarsky

tracing/tracing-subscriber on  david/downcast_ref-registry is 📦 v0.1.5 via v1.39.0
❯ cargo bench --bench=fmt
    Finished release [optimized] target(s) in 0.09s
     Running /local/home/dbarsky/Developer/tracing/target/release/deps/fmt-a1a7fd83bd4e2201
Gnuplot not found, disabling plotting
new_span/single_thread/1
                        time:   [542.32 ns 542.57 ns 542.80 ns]
                        thrpt:  [1.8423 Melem/s 1.8431 Melem/s 1.8439 Melem/s]
                 change:
                        time:   [+1.5380% +1.6310% +1.7080%] (p = 0.00 < 0.05)

davidbarsky

     Running /Users/dbarsky/Developer/Rust/tracing/target/release/deps/filter-1f05138b0829f7a9
static/baseline_single_threaded
                        time:   [109.35 ns 110.75 ns 112.28 ns]
                        change: [-19.618% -12.070% -3.7712%] (p = 0.01 < 0.05)
                        Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
  2 (2.00%) high mild
  2 (2.00%) high severe
static/single_threaded  time:   [59.616 ns 60.292 ns 61.067 ns]
                        change: [-43.963% -36.500% -27.781%] (p = 0.00 < 0.05)

davidbarsky

This branch introduces: 

- A registry build atop of https://github.com/hawkw/sharded-slab. Layers
  are expected to consume this registry through the traits `SpanData`,
  `LookupSpan`, and `LookupMetadata`. Layer-specific data, such as
  formatted spans and events, are stored in the `Extensions` typemap. Data
  is writable via the `ExtensionsMut` view struct of the typemap. This
  enables layers to read and write data that they are specifically
  interested in.

davidbarsky

ctx: Current { inner: None }
Event: Event { fields: ValueSet { query: Set { key: "somekey", value: "somevalue" }, callsite: Identifier(0x10af28f90) }, metadata: Metadata { name: "event src/main.rs:126", target: "application_repro", level: Level(Trace), module_path: "application_repro", location: src/main.rs:126, fields: {query}, callsite: Identifier(0x10af28f90), kind: Kind(Event) }, parent: Current }
ctx: Current { inner: None }
Event: Event { fields: ValueSet { response: Response { status: 200, version: HTTP/1.1, headers: {}, body: Body(Empty) }, callsite: Identifier(0x10af28f80) }, metadata: Metadata { name: "event src/main.rs:131", target: "application_repro", level: Level(Trace), module_path: "application_repro", location: src/main.rs:131, fields: {response}, callsite: Identifier(0x10af28f80), kind: Kind(Event) }, parent: Current }
Span: Span { name: "Task::run", parent: None, metadata: Metadata { name: "Task::run", target: "tokio_executor::threadpool::task", level: Level(Trace), module_path: "tokio_exec

davidbarsky

query CommitHistory($owner: String!, $repositoryName: String! $path: String!) {
  repository(name: $repositoryName, owner: $owner) {
    ref(qualifiedName: "master") {
      target {
        ... on Commit {
          id
          history(first: 10, path: $path) {
            pageInfo {
              hasNextPage
            }

davidbarsky

#![feature(async_await)]

use failure::{Fail, Error};
use std::future::Future;
use std::pin::Pin;

/// `S3Request` is a trait that specifies:
/// - the service request/response pairing.
/// - the service protocol (json, rest-json, rest-xml, or query)
/// - optionally, additional metadata.