-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding multi-thread functionality #48
Comments
I support the request to restrict profiling to a specific thread. janhec describes a rather complex thread structure, but the desire for thread specific profiling arises also in very simple situations. My app has only two threads, one for handling the user input and screen display, the other doing computations in the background. Several access functions are used by both threads. The UI thread can run circles around the block, while the background thread is the bottleneck limiting the performance of the app. I can activate profiling selectively on subproject level, with /GH /Gh compiler switches even on the level of individual .cpp files. Both options do not prevent microprofiler to merge profiling data from both threads. Even if I had a way to restrict profiling to single functions or code sequences, it wouldn't help, as the same code is executed by both threads. |
Great, this will get the job done. If I could ask for something more, I would prefer to have the thread name instead of or in addition to the thread Id. Normally I do not know the id of the thread I am interested in. Of course I can do a "Break All" and look up the Id in the threads window. But seeing the thread name directly in the Combobox would be very convenient. |
Hey Artem,
This looks good.
What I (also) hope for is a shared time frame, to judge the usefulness of
some (harebrained) threading-scheme ;)
I suppose that ought to be deducible from a duration set, but (optional)
times (start/end) of threads would help.
Not totally sure that can be done, you are the expert.
Thanks,
Jan
…On Wed, Feb 26, 2020 at 10:18 PM Artem G. ***@***.***> wrote:
Hey guys!
Will it be sufficient to have such a combobox?
[image: IMG_1350]
<https://user-images.githubusercontent.com/383348/75388174-bf426580-58a1-11ea-84d2-6366eb7fea70.jpeg>
- 'Cumulative' mode will be equivalent to what you currently see;
- 'All' mode will display statisticts, where functions will also have
'thread id' (basically another column in statistics lists) and functions
called from multiple threads are gonna have multiple lines per each thread
they are called from;
- 'Thread #<tid>' will simply display statistics for a thread selected.
Thank you!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#48?email_source=notifications&email_token=ADTBHL54OW6D3YIJ4WQ2QZTRE3MA5A5CNFSM4JQWFF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENB5QNA#issuecomment-591648820>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTBHL4B4OVC3NPUXFJ2CWLRE3MA5ANCNFSM4JQWFF4Q>
.
|
@pk1954 there’s no such thing, as thread name per se in native mode. what i can do is to add a stack trace of resolved functions as a mean to identify a thread visually. but let me first implement the ids - that way we can move fast with development. btw, did you try the last version- 1.6.616? it should’ve worked better - i expected no more problems with broken paths - that kind of stuff... |
@janhec what do you mean by ‘shared time frame’? a percentage among all threads? |
@janhec in the dropdown i can add the start/stop (if complete) time for a thread. is that ok? |
shared time frame: start and end measured against the same start time is
all I mean. Perhaps trivial, but need to know simultaneity.
…On Thu, Feb 27, 2020 at 12:01 AM Artem G. ***@***.***> wrote:
@janhec <https://github.com/janhec> what do you mean by ‘shared time
frame’? a percentage among all threads?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48?email_source=notifications&email_token=ADTBHL5ZIUULWIP3QXC2NU3RE3YC7A5CNFSM4JQWFF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCHHOY#issuecomment-591688635>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTBHL7DJOEDID4GNLWR5KDRE3YC7ANCNFSM4JQWFF4Q>
.
|
Yes, that would be great.
…On Thu, Feb 27, 2020 at 12:02 AM Artem G. ***@***.***> wrote:
@janhec <https://github.com/janhec> in the dropdown i can add the
start/stop (if complete) time for a thread. is that ok?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48?email_source=notifications&email_token=ADTBHLZBWESDX53KQI76SW3RE3YI3A5CNFSM4JQWFF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCHLHY#issuecomment-591689119>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTBHL27QRBP2PPOLXVJ4IDRE3YI3ANCNFSM4JQWFF4Q>
.
|
ok, let me see what flexibility (in terms of dynamic updates - so that the times be updated as they observed) can i get from standard combobox. i plan to switch to completely custom controls (due to performance and portability reasons), but that is not gonna happen for a few months... |
I didn't try version 1.6.616? so far, will give you feedback later. |
@pk1954 those are the names visual studio infer from stack locations- i meant there’s no api to set/get it. it’s possible though to associate a name manually with a tls (or other thread-specific location in fs/gs segment in x86/x64) |
@pk1954 ha, seems my knowledge is outdated - they’ve added it in win10 finally: |
thanks! |
i can use it, when running on win 10, of course. |
Great! Thank you |
cheers, guys! you’re very helpful! |
We should come together sometime!
…On Thu, Feb 27, 2020 at 12:26 AM Artem G. ***@***.***> wrote:
cheers, guys! you’re very helpful!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#48?email_source=notifications&email_token=ADTBHL4FNYY5V6EF7DJCHMLRE33DPA5CNFSM4JQWFF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCJH4Q#issuecomment-591696882>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADTBHL2CKX3GVVKPL6YLMMDRE33DPANCNFSM4JQWFF4Q>
.
|
Just to mark the progress... |
Hi Artem, |
Hi Peter! Can you please send me logfiles from here: %LOCALAPPDATA%\.MicroProfiler\* ? There're paths exposed in them, so you can just hit me up on LinkedIn for a private message if you don't like that info go public. Thanks! |
I don't see anything attached here or in the mail... |
Can you just attach it to the message? It gets abridged, otherwise: getpid(): 3360 self: c:\users\peter\appdata\local\microsoft\visualstudio\16.0_dae80a5f\extensions\0bmrhsvd.zsk\micro-profiler_frontend.dll exe: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe vs.m |
Thanks! |
It really seems to have been a random effect. Just out of curiosity I uninstalled MicroProfiler and reinstalled it. This time everything worked from the beginning. |
just make sure, that it doesn’t reappear on the second run. i’ll look into how to change the environment before it has spread to child processes
|
Hey guys! Please, check out for this release: https://github.com/tyoma/micro-profiler/releases/download/v1.6.619.0/micro-profiler.v1.6.619.0.vsix - it has the issue implemented. If you're satisfied, please close it. thanks! |
It works and is very useful. Issue can be closed from my point of view. |
I'm looking for an effective way to profile a multithread operation, which is complicated because a thread may fork again. Is it possible to add thread information/PID into the mix? That might help to fix the sweet point in the number and division of threads, I hope.
Admittedly, I do not have a very clear picture of this, but I hope a relatively minor report addition may go a long way, for me, at least.
Further elaboration:
I tried to use the profiler for optimizing a multi-thread proces, but couldn't do it, because I could not pinpoint real bottlenecks. Especially since individual threads may need quite different runtimes. The aim is to prioritize threading to ensure that the total runtime equals the longest run (or as close as possible). That is basically done by "subthreading" (my term but I think it is clear). So main threads are started only when there is a bit of unused cpu capacity available.
There are really two optimization problems:
Reading up a bit I realize that this is a tall order even in terms of theoretical methods. But anyhow, advice and or more data (e.g. an absolute timeline) could help.
The text was updated successfully, but these errors were encountered: