Comments (11)
I guess it depends on what you mean by "when I used it".
THREAD_CPU_TIME logs the time spent along with the thread id (tid), and it is the per-thread time. PROC_CPU_TIME is the time spent by the whole process.
If by "using it" you mean something like modifying test_counters
from the workflow_demo.py
script to include THREAD_CPU_TIME
, then you're aggregating the time from all the threads, which would be the time spent by the whole application. This is because the current version of workflow_demo.py
just aggregates on counterType
, which basically ignores the fact that some counters are per-thread.
You could somewhat easily modify the script to make it work for you, though. The tid lives inside the unit
object, in unit.properties.customProps['tid']
. You could modify the for unit in trace.executionUnits.values():
loop inside the syscounters()
function to aggregate not only on counterType
, but on (counterType, tid)
tuples, and that would give you the per-thread granularity that you're looking for.
from profilo.
I'm not sure I fully understand the question, but here goes.
You could do something like this:
for unit in trace.executionUnits.values():
curr_tid = unit.properties.customProps['tid']
for block_id in unit.blocks:
block = trace.blocks[block_id]
for point in block.points:
counter = point.properties.counterProps.get(tt.CounterUnit.ITEMS, None)
if not counter:
continue
for counterType, count in counter.items():
counters[(curr_tid, counterType)].append((point.timestamp, count))
Your counters
map will now be indexed by (tid, counterType)
tuples, essentially giving you the per-thread granularity.
Is this what you were asking?
from profilo.
Commit d8e21bb addresses this problem.
Now the thread's name is available under unit.properties.coreProps['name']
. We also added the thread's priority under unit.properties.coreProps['priority']
.
Please close this issue if you think it addresses your original concern.
from profilo.
The mechanism we use to find a thread's name consists on reading /proc/self/task/<tid>/comm
. The /proc/self/task
directory only contains entries for threads that are currently alive, so as soon as a thread dies there's no way for us to get its name.
Now, this information is obtained by Profilo by means of the threadmetadata
provider. This provider is called only when a trace stops, and the reason for this is that the process mentioned above is expensive (and there might be a pretty large number of threads running), so we don't want to do it too often. So, the "tradeoff" here is not hitting performance - by calling this provider only at the end of a trace - at the cost of not having the name of every single thread that was spawned.
However, you can change this behavior if you decide that you're OK with the performance hit. For instance, you can spawn a thread that calls this mechanism in some sort of loop (see https://github.com/facebookincubator/profilo/blob/master/java/main/com/facebook/profilo/provider/stacktrace/StackFrameThread.java#L143-L174 and https://github.com/facebookincubator/profilo/blob/master/cpp/profiler/SamplingProfiler.cpp#L404-L438 for a way to do this) so that you get the names of all threads.
from profilo.
The thread cpu time is consumed in ms:
void threadCountersCallback(
uint32_t tid,
util::ThreadStatInfo& prevInfo,
util::ThreadStatInfo& currInfo) {
if (prevInfo.highPrecisionCpuTimeMs != 0 &&
(currInfo.availableStatsMask & StatType::HIGH_PRECISION_CPU_TIME)) {
// Don't log the initial value
logCPUTimeCounter(
prevInfo.highPrecisionCpuTimeMs, currInfo.highPrecisionCpuTimeMs, tid);
} else if (
prevInfo.cpuTimeMs != 0 &&
(currInfo.availableStatsMask & StatType::CPU_TIME)) {
// Don't log the initial value
logCPUTimeCounter(prevInfo.cpuTimeMs, currInfo.cpuTimeMs, tid);
}
...
inline void logCPUTimeCounter(long prevCpuTime, long currCpuTime, int tid) {
const auto kThresholdMs = 1;
logMonotonicCounter(
prevCpuTime,
currCpuTime,
tid,
QuickLogConstants::THREAD_CPU_TIME,
kThresholdMs);
}
from profilo.
When i used it, i see that it does not only provide the cpu time used in the thread that i call method Start() only but it provides the cpu time used in the whole application, am i right?
from profilo.
Yes i modified the test_counters to include THREAD_CPU_TIME, but how can i know the thread id of the thread i am tracing?
from profilo.
My question is that how can i know which threads in the application correspond to which tid in the trace.
from profilo.
Ah, I think I see what you mean.
The threadmetadata
provider, which is enabled by default on the sample app, logs TRACE_THREAD_NAME
entries, which should give us the information that we need. However, the current version of the parser does not handle these entries, so all that we have is the tid. I'll start working on a fix for this and let you know when it's ready =)
from profilo.
thank you for your quick response!!
from profilo.
Just test it and now i can get the thread's name instead of thread id, but i notice that profilo can only give me the name i set in the thread's constructor if the thread is still running when stopTrace() is called, if the thread dies before calling the stopTrace(), profilo give me something like Thread_3443.
from profilo.
Related Issues (20)
- Migration Website to Docusaurus 2 Alpha HOT 3
- Unknown IDs in flame graph when stacks are produced HOT 5
- Missing framework frames information in stacktraces (pre-lollipop devices) HOT 2
- why libprofiloextapi.so not exits ? HOT 1
- How to keep collect stack safety in profiler? HOT 1
- Python scripts throws errors HOT 14
- Crash on API level 28 when SoLoader initialise the .so libraries HOT 6
- Meaning of CPU time in ProcessCounters HOT 3
- Gradle native builds HOT 1
- Meaning of Trace.In-Memory HOT 4
- NativeTracer HOT 1
- android 7.1.2 arm64 unwind support HOT 2
- profilo unwind cannot work on 6.0 with arm64 devices HOT 2
- How do I run the project on Android studio? HOT 2
- Is there a way to generate file that can be analyze by perfetto (systrace file)? HOT 1
- ANR when init Profilo? HOT 1
- How to getLineNum from unwind? HOT 1
- Stable for production usage? HOT 2
- Native code support (C/C++/Rust/Dart)? HOT 2
- dex version 39 can not get stacks HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from profilo.