2017-07-20 19:43:35 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2017 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "SkChromeTracingTracer.h"
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
#include "SkJSONWriter.h"
|
2017-07-20 19:43:35 +00:00
|
|
|
#include "SkThreadID.h"
|
|
|
|
#include "SkTraceEvent.h"
|
|
|
|
#include "SkOSFile.h"
|
|
|
|
#include "SkOSPath.h"
|
|
|
|
#include "SkStream.h"
|
|
|
|
|
|
|
|
#include <chrono>
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
/**
|
|
|
|
* All events have a fixed block of information (TraceEvent), plus variable length payload:
|
|
|
|
* {TraceEvent} {TraceEventArgs} {Inline Payload}
|
|
|
|
*/
|
|
|
|
struct TraceEventArg {
|
|
|
|
uint8_t fArgType;
|
|
|
|
const char* fArgName;
|
|
|
|
uint64_t fArgValue;
|
|
|
|
};
|
|
|
|
|
|
|
|
// These fields are ordered to minimize size due to alignment. Argument types could be packed
|
|
|
|
// better, but very few events have many arguments, so the net loss is pretty small.
|
|
|
|
struct TraceEvent {
|
|
|
|
char fPhase;
|
|
|
|
uint8_t fNumArgs;
|
|
|
|
uint32_t fSize;
|
|
|
|
|
|
|
|
const char* fName;
|
|
|
|
// TODO: Merge fID and fClockEnd (never used together)
|
|
|
|
uint64_t fID;
|
|
|
|
uint64_t fClockBegin;
|
|
|
|
uint64_t fClockEnd;
|
|
|
|
SkThreadID fThreadID;
|
|
|
|
|
|
|
|
TraceEvent* next() {
|
|
|
|
return reinterpret_cast<TraceEvent*>(reinterpret_cast<char*>(this) + fSize);
|
|
|
|
}
|
|
|
|
TraceEventArg* args() {
|
|
|
|
return reinterpret_cast<TraceEventArg*>(this + 1);
|
|
|
|
}
|
|
|
|
char* stringTable() {
|
|
|
|
return reinterpret_cast<char*>(this->args() + fNumArgs);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-07-24 15:38:01 +00:00
|
|
|
SkChromeTracingTracer::SkChromeTracingTracer(const char* filename) : fFilename(filename) {
|
2017-08-16 14:31:29 +00:00
|
|
|
this->createBlock();
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
SkChromeTracingTracer::~SkChromeTracingTracer() {
|
|
|
|
this->flush();
|
|
|
|
}
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
void SkChromeTracingTracer::createBlock() {
|
|
|
|
fCurBlock.fBlock = BlockPtr(new uint8_t[kBlockSize]);
|
|
|
|
fCurBlock.fEventsInBlock = 0;
|
|
|
|
fCurBlockUsed = 0;
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
SkEventTracer::Handle SkChromeTracingTracer::appendEvent(const void* data, size_t size) {
|
|
|
|
SkASSERT(size > 0 && size <= kBlockSize);
|
|
|
|
|
2017-07-24 15:38:01 +00:00
|
|
|
SkAutoMutexAcquire lock(fMutex);
|
2017-08-16 14:31:29 +00:00
|
|
|
if (fCurBlockUsed + size > kBlockSize) {
|
2017-07-24 15:38:01 +00:00
|
|
|
fBlocks.push_back(std::move(fCurBlock));
|
2017-08-16 14:31:29 +00:00
|
|
|
this->createBlock();
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
2017-08-16 14:31:29 +00:00
|
|
|
memcpy(fCurBlock.fBlock.get() + fCurBlockUsed, data, size);
|
|
|
|
Handle handle = reinterpret_cast<Handle>(fCurBlock.fBlock.get() + fCurBlockUsed);
|
|
|
|
fCurBlockUsed += size;
|
|
|
|
fCurBlock.fEventsInBlock++;
|
|
|
|
return handle;
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
|
|
|
|
2017-07-20 19:43:35 +00:00
|
|
|
SkEventTracer::Handle SkChromeTracingTracer::addTraceEvent(char phase,
|
|
|
|
const uint8_t* categoryEnabledFlag,
|
|
|
|
const char* name,
|
|
|
|
uint64_t id,
|
|
|
|
int numArgs,
|
|
|
|
const char** argNames,
|
|
|
|
const uint8_t* argTypes,
|
|
|
|
const uint64_t* argValues,
|
|
|
|
uint8_t flags) {
|
2017-07-21 19:30:14 +00:00
|
|
|
// TODO: Respect flags (or assert). INSTANT events encode scope in flags, should be stored
|
|
|
|
// using "s" key in JSON. COPY flag should be supported or rejected.
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
// Figure out how much extra storage we need for copied strings
|
|
|
|
int size = static_cast<int>(sizeof(TraceEvent) + numArgs * sizeof(TraceEventArg));
|
|
|
|
for (int i = 0; i < numArgs; ++i) {
|
|
|
|
if (TRACE_VALUE_TYPE_COPY_STRING == argTypes[i]) {
|
|
|
|
skia::tracing_internals::TraceValueUnion value;
|
|
|
|
value.as_uint = argValues[i];
|
|
|
|
size += strlen(value.as_string) + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-24 17:22:32 +00:00
|
|
|
size = SkAlign8(size);
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
SkSTArray<128, uint8_t, true> storage;
|
|
|
|
uint8_t* storagePtr = storage.push_back_n(size);
|
2017-07-21 19:30:14 +00:00
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
TraceEvent* traceEvent = reinterpret_cast<TraceEvent*>(storagePtr);
|
|
|
|
traceEvent->fPhase = phase;
|
|
|
|
traceEvent->fNumArgs = numArgs;
|
|
|
|
traceEvent->fSize = size;
|
|
|
|
traceEvent->fName = name;
|
|
|
|
traceEvent->fID = id;
|
|
|
|
traceEvent->fClockBegin = std::chrono::steady_clock::now().time_since_epoch().count();
|
|
|
|
traceEvent->fClockEnd = 0;
|
|
|
|
traceEvent->fThreadID = SkGetThreadID();
|
|
|
|
|
|
|
|
TraceEventArg* traceEventArgs = traceEvent->args();
|
|
|
|
char* stringTableBase = traceEvent->stringTable();
|
|
|
|
char* stringTable = stringTableBase;
|
2017-07-24 15:38:01 +00:00
|
|
|
for (int i = 0; i < numArgs; ++i) {
|
2017-08-16 14:31:29 +00:00
|
|
|
traceEventArgs[i].fArgName = argNames[i];
|
|
|
|
traceEventArgs[i].fArgType = argTypes[i];
|
2017-07-24 15:38:01 +00:00
|
|
|
if (TRACE_VALUE_TYPE_COPY_STRING == argTypes[i]) {
|
2017-08-16 14:31:29 +00:00
|
|
|
// Just write an offset into the arguments array
|
|
|
|
traceEventArgs[i].fArgValue = stringTable - stringTableBase;
|
|
|
|
|
|
|
|
// Copy string into our buffer (and advance)
|
2017-07-24 15:38:01 +00:00
|
|
|
skia::tracing_internals::TraceValueUnion value;
|
|
|
|
value.as_uint = argValues[i];
|
2017-08-16 14:31:29 +00:00
|
|
|
while (*value.as_string) {
|
|
|
|
*stringTable++ = *value.as_string++;
|
|
|
|
}
|
|
|
|
*stringTable++ = 0;
|
2017-07-24 15:38:01 +00:00
|
|
|
} else {
|
2017-08-16 14:31:29 +00:00
|
|
|
traceEventArgs[i].fArgValue = argValues[i];
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
return this->appendEvent(storagePtr, size);
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void SkChromeTracingTracer::updateTraceEventDuration(const uint8_t* categoryEnabledFlag,
|
|
|
|
const char* name,
|
|
|
|
SkEventTracer::Handle handle) {
|
|
|
|
// We could probably get away with not locking here, but let's be totally safe.
|
|
|
|
SkAutoMutexAcquire lock(fMutex);
|
|
|
|
TraceEvent* traceEvent = reinterpret_cast<TraceEvent*>(handle);
|
2017-08-16 14:31:29 +00:00
|
|
|
traceEvent->fClockEnd = std::chrono::steady_clock::now().time_since_epoch().count();
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
static void trace_value_to_json(SkJSONWriter* writer, uint64_t argValue, uint8_t argType,
|
|
|
|
const char* stringTableBase) {
|
2017-08-01 14:23:38 +00:00
|
|
|
skia::tracing_internals::TraceValueUnion value;
|
|
|
|
value.as_uint = argValue;
|
|
|
|
|
|
|
|
switch (argType) {
|
|
|
|
case TRACE_VALUE_TYPE_BOOL:
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendBool(value.as_bool);
|
|
|
|
break;
|
2017-08-01 14:23:38 +00:00
|
|
|
case TRACE_VALUE_TYPE_UINT:
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendU64(value.as_uint);
|
|
|
|
break;
|
2017-08-01 14:23:38 +00:00
|
|
|
case TRACE_VALUE_TYPE_INT:
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendS64(value.as_int);
|
|
|
|
break;
|
2017-08-01 14:23:38 +00:00
|
|
|
case TRACE_VALUE_TYPE_DOUBLE:
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendDouble(value.as_double);
|
|
|
|
break;
|
2017-08-01 14:23:38 +00:00
|
|
|
case TRACE_VALUE_TYPE_POINTER:
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendPointer(value.as_pointer);
|
|
|
|
break;
|
2017-08-01 14:23:38 +00:00
|
|
|
case TRACE_VALUE_TYPE_STRING:
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendString(value.as_string);
|
|
|
|
break;
|
2017-08-16 14:31:29 +00:00
|
|
|
case TRACE_VALUE_TYPE_COPY_STRING:
|
|
|
|
writer->appendString(stringTableBase + value.as_uint);
|
|
|
|
break;
|
2017-08-01 14:23:38 +00:00
|
|
|
default:
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendString("<unknown type>");
|
|
|
|
break;
|
2017-08-01 14:23:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-16 20:56:04 +00:00
|
|
|
namespace {
|
|
|
|
|
|
|
|
struct TraceEventSerializationState {
|
|
|
|
TraceEventSerializationState(uint64_t clockOffset)
|
|
|
|
: fClockOffset(clockOffset), fNextThreadID(0) {}
|
|
|
|
|
|
|
|
int getShortThreadID(SkThreadID id) {
|
|
|
|
if (int* shortIDPtr = fShortThreadIDMap.find(id)) {
|
|
|
|
return *shortIDPtr;
|
|
|
|
}
|
|
|
|
int shortID = fNextThreadID++;
|
|
|
|
fShortThreadIDMap.set(id, shortID);
|
|
|
|
return shortID;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t fClockOffset;
|
|
|
|
SkTHashMap<uint64_t, const char*> fBaseTypeResolver;
|
|
|
|
int fNextThreadID;
|
|
|
|
SkTHashMap<SkThreadID, int> fShortThreadIDMap;
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
2017-08-16 14:31:29 +00:00
|
|
|
|
|
|
|
static void trace_event_to_json(SkJSONWriter* writer, TraceEvent* traceEvent,
|
2017-08-16 20:56:04 +00:00
|
|
|
TraceEventSerializationState* serializationState) {
|
2017-08-01 14:23:38 +00:00
|
|
|
// We track the original (creation time) "name" of each currently live object, so we can
|
|
|
|
// automatically insert "base_name" fields in object snapshot events.
|
2017-08-16 20:56:04 +00:00
|
|
|
auto baseTypeResolver = &(serializationState->fBaseTypeResolver);
|
2017-08-16 14:31:29 +00:00
|
|
|
if (TRACE_EVENT_PHASE_CREATE_OBJECT == traceEvent->fPhase) {
|
|
|
|
SkASSERT(nullptr == baseTypeResolver->find(traceEvent->fID));
|
|
|
|
baseTypeResolver->set(traceEvent->fID, traceEvent->fName);
|
|
|
|
} else if (TRACE_EVENT_PHASE_DELETE_OBJECT == traceEvent->fPhase) {
|
|
|
|
SkASSERT(nullptr != baseTypeResolver->find(traceEvent->fID));
|
|
|
|
baseTypeResolver->remove(traceEvent->fID);
|
2017-08-01 14:23:38 +00:00
|
|
|
}
|
|
|
|
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->beginObject();
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
char phaseString[2] = { traceEvent->fPhase, 0 };
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendString("ph", phaseString);
|
2017-08-16 14:31:29 +00:00
|
|
|
writer->appendString("name", traceEvent->fName);
|
|
|
|
if (0 != traceEvent->fID) {
|
2017-08-01 14:23:38 +00:00
|
|
|
// IDs are (almost) always pointers
|
2017-08-16 14:31:29 +00:00
|
|
|
writer->appendPointer("id", reinterpret_cast<void*>(traceEvent->fID));
|
2017-08-01 14:23:38 +00:00
|
|
|
}
|
2017-08-16 20:56:04 +00:00
|
|
|
|
|
|
|
// Offset timestamps to reduce JSON length, then convert nanoseconds to microseconds
|
|
|
|
// (standard time unit for tracing JSON files).
|
|
|
|
uint64_t relativeTimestamp = static_cast<int64_t>(traceEvent->fClockBegin -
|
|
|
|
serializationState->fClockOffset);
|
|
|
|
writer->appendDoubleDigits("ts", static_cast<double>(relativeTimestamp) * 1E-3, 3);
|
2017-08-16 14:31:29 +00:00
|
|
|
if (0 != traceEvent->fClockEnd) {
|
|
|
|
double dur = static_cast<double>(traceEvent->fClockEnd - traceEvent->fClockBegin) * 1E-3;
|
2017-08-16 20:56:04 +00:00
|
|
|
writer->appendDoubleDigits("dur", dur, 3);
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
2017-08-16 20:56:04 +00:00
|
|
|
|
|
|
|
writer->appendS64("tid", serializationState->getShortThreadID(traceEvent->fThreadID));
|
2017-07-21 19:30:14 +00:00
|
|
|
// Trace events *must* include a process ID, but for internal tools this isn't particularly
|
|
|
|
// important (and certainly not worth adding a cross-platform API to get it).
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->appendS32("pid", 0);
|
2017-08-01 14:23:38 +00:00
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
if (traceEvent->fNumArgs) {
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->beginObject("args");
|
2017-08-16 14:31:29 +00:00
|
|
|
const char* stringTable = traceEvent->stringTable();
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
bool addedSnapshot = false;
|
2017-08-16 14:31:29 +00:00
|
|
|
if (TRACE_EVENT_PHASE_SNAPSHOT_OBJECT == traceEvent->fPhase &&
|
|
|
|
baseTypeResolver->find(traceEvent->fID) &&
|
|
|
|
0 != strcmp(*baseTypeResolver->find(traceEvent->fID), traceEvent->fName)) {
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
// Special handling for snapshots where the name differs from creation.
|
|
|
|
writer->beginObject("snapshot");
|
2017-08-16 14:31:29 +00:00
|
|
|
writer->appendString("base_type", *baseTypeResolver->find(traceEvent->fID));
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
addedSnapshot = true;
|
|
|
|
}
|
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
for (int i = 0; i < traceEvent->fNumArgs; ++i) {
|
|
|
|
const TraceEventArg* arg = traceEvent->args() + i;
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
// TODO: Skip '#'
|
2017-08-16 14:31:29 +00:00
|
|
|
writer->appendName(arg->fArgName);
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
if (arg->fArgName && '#' == arg->fArgName[0]) {
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->beginObject();
|
|
|
|
writer->appendName("id_ref");
|
2017-08-16 14:31:29 +00:00
|
|
|
trace_value_to_json(writer, arg->fArgValue, arg->fArgType, stringTable);
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer->endObject();
|
2017-08-01 14:23:38 +00:00
|
|
|
} else {
|
2017-08-16 14:31:29 +00:00
|
|
|
trace_value_to_json(writer, arg->fArgValue, arg->fArgType, stringTable);
|
2017-07-20 19:43:35 +00:00
|
|
|
}
|
|
|
|
}
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
|
|
|
|
if (addedSnapshot) {
|
|
|
|
writer->endObject();
|
2017-08-01 14:23:38 +00:00
|
|
|
}
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
|
|
|
|
writer->endObject();
|
2017-07-20 19:43:35 +00:00
|
|
|
}
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
|
|
|
|
writer->endObject();
|
2017-07-20 19:43:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void SkChromeTracingTracer::flush() {
|
2017-07-24 15:38:01 +00:00
|
|
|
SkAutoMutexAcquire lock(fMutex);
|
|
|
|
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
SkString dirname = SkOSPath::Dirname(fFilename.c_str());
|
|
|
|
if (!dirname.isEmpty() && !sk_exists(dirname.c_str(), kWrite_SkFILE_Flag)) {
|
|
|
|
if (!sk_mkdir(dirname.c_str())) {
|
|
|
|
SkDebugf("Failed to create directory.");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
SkFILEWStream fileStream(fFilename.c_str());
|
|
|
|
SkJSONWriter writer(&fileStream, SkJSONWriter::Mode::kFast);
|
|
|
|
writer.beginArray();
|
|
|
|
|
2017-08-16 20:56:04 +00:00
|
|
|
uint64_t clockOffset = 0;
|
|
|
|
if (fBlocks.count() > 0) {
|
|
|
|
clockOffset = reinterpret_cast<TraceEvent*>(fBlocks[0].fBlock.get())->fClockBegin;
|
|
|
|
} else if (fCurBlock.fEventsInBlock > 0) {
|
|
|
|
clockOffset = reinterpret_cast<TraceEvent*>(fCurBlock.fBlock.get())->fClockBegin;
|
|
|
|
}
|
|
|
|
|
|
|
|
TraceEventSerializationState serializationState(clockOffset);
|
2017-07-24 15:38:01 +00:00
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
auto event_block_to_json = [](SkJSONWriter* writer, const TraceEventBlock& block,
|
2017-08-16 20:56:04 +00:00
|
|
|
TraceEventSerializationState* serializationState) {
|
2017-08-16 14:31:29 +00:00
|
|
|
TraceEvent* traceEvent = reinterpret_cast<TraceEvent*>(block.fBlock.get());
|
|
|
|
for (int i = 0; i < block.fEventsInBlock; ++i) {
|
2017-08-16 20:56:04 +00:00
|
|
|
trace_event_to_json(writer, traceEvent, serializationState);
|
2017-08-16 14:31:29 +00:00
|
|
|
traceEvent = traceEvent->next();
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
2017-08-16 14:31:29 +00:00
|
|
|
};
|
2017-07-24 15:38:01 +00:00
|
|
|
|
2017-08-16 14:31:29 +00:00
|
|
|
for (int i = 0; i < fBlocks.count(); ++i) {
|
2017-08-16 20:56:04 +00:00
|
|
|
event_block_to_json(&writer, fBlocks[i], &serializationState);
|
2017-07-24 15:38:01 +00:00
|
|
|
}
|
2017-08-16 20:56:04 +00:00
|
|
|
event_block_to_json(&writer, fCurBlock, &serializationState);
|
2017-07-24 15:38:01 +00:00
|
|
|
|
Added SkJSONWriter
This is a stand-alone helper class for writing properly
structured JSON to an SkWStream. It currently solves two
problems (although this CL only uses it in one context):
1) Performance. Writing out JSON this way is about 10x
faster than using JSONCPP. For the large amounts of data
generated by the tracing system, that's a big win.
2) Makes it easy to emit structured JSON from code that's
not fully centralized. We'd like to spit out JSON that
describes a GrContext, GrGpu, GrCaps, etc... Doing that
with simple string manipulation is complex, and spreads
this logic over all those functions. Using JSONCPP adds
yet another (large) third party library dependency (that
we only build into our own tools right now).
This went through several revisions. I originally planned
it as a stateful SkString wrapper, so the user could just
build their JSON as a string. That's O(N^2), though,
because SkString grows by a (small) constant amount. Even
using a better growth strategy still means needing RAM
for all the resulting text, which is usually pointless.
This version has a constant memory cost, so writing huge
amounts of JSON to disk (tracing a long DM run can emit
100's of MBs) doesn't stress resources.
Bug: skia:
Change-Id: Ia716524b246db0f97d332da60d2ce9903069e748
Reviewed-on: https://skia-review.googlesource.com/31204
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
2017-08-09 13:25:39 +00:00
|
|
|
writer.endArray();
|
|
|
|
writer.flush();
|
|
|
|
fileStream.flush();
|
2017-07-20 19:43:35 +00:00
|
|
|
}
|