verysleepy / verysleepy

Very Sleepy, a sampling CPU profiler for Windows

Very Sleepy

This is Very Sleepy, a sampling CPU profiler for Windows with a wxWidgets-based GUI.

Features

• Simple user interface
• Microsoft Symbol Server support
• Command-line operation
• MinGW support
• Late symbol resolution

Documentation

Very Sleepy documentation is available on the GitHub project wiki.

Download

Official releases can be downloaded from the project's website, or from the GitHub releases page.

For the latest development version, you can download the latest AppVeyor artifact.

History

Version 0.92 (under development):

• Do not include time while paused in sample durations
• Add command-line switch /d to wait before starting profiler
• Contributed by aaalexandrov:
  • Add sample filtering by thread (#86)
  • Profile new threads as they are created (#88)

Version 0.91 (2021-08-19):

• Rename project back to Very Sleepy (this fork repository is now the official repository)
• Use Dr. MinGW to resolve MinGW symbols by default
• Update Wine DbgHelp for Windows
• Improve and greatly simplify build process (#40)
• Add continuous integration via AppVeyor
• Improve Visual Studio 2015 support (#28)
• More user interface fixes and improvements
• Contributed by Bernat Muñoz Garcia:
  • Use Scintilla for syntax highlighting (#16)
• Contributed by Ashod:
  • 64-bit fixes (#21)
• Contributed by k4hvd1:
  • Added command-line option /a to profile an existing process by its process ID (#30)
• Contributed by Markus Gaisbauer:
  • Added "Total CPU time" column (#37)
  • Improved handling of processes with many threads (#38)
• Contributed by Bernhard Schelling:
  • Added Callgrind format file export feature (#46)
  • Fixed symbols (PDB files) not being unloaded after detaching (#57)
  • Improved jumping to source lines from list views (#58)
• Contributed by rammerchoi:
  • Added command-line switch '/mt' and '/mbt' (#48)
• Contributed by Graeme Kelly:
  • Added display of thread names on threads lists (#60)
  • Added column headers to exported CSV files (#62)
• Contributed by Yujiang Wang:
  • Fixed missing buttons for very long paths (#65)
  • Updated DbgHelp to 10.0.17763.1 (#65)
• Contributed by djdron:
  • Improved HDPI support (#74)
  • Fixed some memory leaks (#75)
  • Updated Dr.MinGW (#77)

Version 0.90 (2014-12-23):

• Redesign parts of the file format and internal database representation, to allow more exact late symbol loading, as well as a disassembler view in the future
• Add an "Address" column to all function lists
  • For the call stack and callers view, the address specifies the address past the call instruction
• Several fixes to the crash reporter
• Use wxWidgets 2.9.5
• Fix problems caused by dbghelp.dll hijacking
• Fix handling of symbols containing whitespace characters
• More user interface improvements
• Contributed by Unknown W. Brackets:
  • 64-bit fixes (#6)
• Contributed by Michael Vance:
  • Add CSV export for the callstack view
  • UI fixes and code cleanup

Version 0.83 (2013-08-22):

• Rename fork to "Very Sleepy CS"
• Numerous user interface performance, responsiveness and usability improvements
• Allow specifying additional symbol search paths
• Add Back and Forward menu items and hotkeys for function list navigation
• Improve overall performance
• Add late symbol loading by saving a minidump during profiling
• Install 32-bit version alongside 64-bit version
• Contributed by Richard Munn:
  • Added a time limit option to the interface (#1)
  • Added function highlighting and filtering (#2)
  • Interface improvements (#3)

First fork release (2013-01-11):

• GitHub repository created
• Fix several issues with the /r command-line option
• Various UI improvements
• Don't completely abort due to one failed GetThreadContext call (fixes "Error: ProfilerExcep: GetThreadContext failed." errors by ignoring the occasional seemingly-harmless error condition)

Older changes

Changes before this repository's creation can be found on the project's website.

Building

Prerequisites

• Visual C++ 2010 or newer
• CMake (for Dr. MinGW)
• 7-Zip (for unpacking MinGW)
• InnoSetup 5 (for building an installer)

Instructions

Third party dependencies are registered using git submodules, so you will need to either clone with the --recursive flag, or run git submodule update --init after cloning.

The build.cmd batch file will attempt to build Very Sleepy and its dependencies.

Alternatively, you can build Dr. MinGW using the thirdparty/drmingw_build_mingw.cmd batch file, then use the Visual Studio solution file (sleepy.sln) to build everything else.

Contributing

If you'd like to contribute a patch, please open a pull request. I'll try to review and merge it as soon as my time will allow.

Bug reports and feature requests are welcome as well -- please file them as GitHub issues.

verysleepy's Issues

profiling always shows equal values for exclusive and inclusive

No matter how I try compiling, sleepy is giving me identical values for exclusive and inclusive times for all functions. It appears to actually be the Exclusive time, since they all add up to 100%.

I'm using msys2's gcc with arguments -std=c11 -O3 -Wall -gdwarf-2 -fno-omit-frame-pointer. I've tried adding -g, but it doesn't seem to change things.

I'm running Very Sleepy CS 0.90 and gcc 4.9.2.

Commas are not properly escaped in CSV-exported files

In C++, commas often appear in templated classes/functions, for instance:

std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign

At the moment, CSV files exported from Very Sleepy 0.9 are messed up because of these commas, and thus cannot be easily imported into e.g. LibreOffice for further analysis.

What about Very Sleepy's Windows 10 compatibility?

Good afternoon,
I've been working with Very Sleepy before, while my computer was still a Windows 7 one, and I had the impression that the tool was working fine.

Now I'm faced with quite some instabilities:

1. When I run the application, there is an application which is not visible in the list of processes. In order to get it working, I need to re-install it and choose to start the application at the end of the installation.
2. Once the profiled application is stopped, I stop the profiling, and then I see the "dialog box" "Waiting for symbol query to start ...", but this dialog box doesn't stop. In the code snippet I've seen that the display of this dialog box is implemented using a "while(true)" loop. Maybe it's a good idea to use a timer for this feature. In case of a time-out another dialog can be shown, mentioning what to do in order not to stay blocked.

Best regards
Dominique Descamps

The latest build has been deleted from AppVeyor.

This webpage https://ci.appveyor.com/project/CyberShadow/verysleepy/branch/master/artifacts
says:

Artifacts older than 6 months are automatically deleted.

Entry Point Not Found

Just tried to launch Very Sleepy CS on Windows 8.1 64bit.

I'm getting an error dialog saying:

The procedure entry point SetCheckUserInterruptShared could not be located in the dynamic link library C:\WINDOWS\SYSTEM32\dbgeng.dll

Oddly enough, verysleepy_0_82.exe from which you forked works.

Command line profiling doesn't import all symbols

If I run
sleepy.exe /c foo.exe, I get only the below symbols

But if I run sleepy.exe and then select the process from the GUI, a lot more symbols show up.

The pictures aren't profiling the exact same time, but you get the idea. I'm trying to profile a 2-second-long program, so selecting the process from the GUI won't work very well anymore. Thanks!

profiling executable compiled with gcc's -flto is messed up

It seems that when trying to profile programs that have been compiled with -flto (link time optimization), the resulting profile is all messed up. I'm getting a bunch of duplicated Names, where clicking on them usually goes to the wrong functions. Sometimes it goes to the right one and the per-line timings seem to add up correctly.

I need to compile with flto because otherwise gcc won't inline some cross-file functions that need to be inlined. I'm not sure if the fault is with gcc not outputting the correct data, or with sleepy not being able to handle what it gets.

I'm running Very Sleepy CS 0.90 and gcc 4.9.2.

Can`t change "Symbol search path"

First time this option work normally, but after restart program impossible to change path, add new or move up/down.
I found "SymbolSearchPath" parameter in registry and clear him. After I can add new paths, but only first time.

Symbol downloading woes

Several issues I am encountering when trying to download symbols:

• When running in non-admin mode, it tries to download, but doesn't actually download anything. When running in admin mode, it tries to download, and actually does. Reproducible. Maybe put something in the manifest so that on start, a UAC prompt shows up so it always runs in admin mode? Does this only happen on my system?
• Downloading is very slow. This is probably the fault of the Microsoft Symbol server.
• When downloading, sometimes the displayed % of the current file gets updated in the bottom text window, that's it. Would be nice to add a more verbose download monitor, with kb/s etc.
• When downloading, sometimes the currently downloaded file is displayed in the bottom text window. But sometimes nothing is displayed, although looking at my AppData/Local/sleepy Directory, I see new directories being created. Shouldn't these Directory/File names be displayed in the text window?
• When downloading, a window shows up "Downloading symbols...".
  • The progress bar is only a constantly moving animation without information as there is probably no data set about current progress and 0%/100% values. Please provide data for the progress bar.
  • The "Close" Button is greyed out, so you can't cancel the download. You have to close Very Sleepy, each time in a "Very Sleepy doesn't react, force close?" prompt. Please allow us to cancel and restart the downloading progress, as the servers often have hiccups.

mingw-w64 compiled executables' symbols not recognized

The title says it all. I built an executable with mingw-w64 (latest official, G++ 8.1.0), of course with the -g flag, and it shows just addresses, not actual function names (and doesn't display code).

Filters cause wrong function highlight.

When filtering by module or source file (and possibly others) selecting a function from the list boxes in the Averages or Call Stacks tabs selects the wrong function in the main Functions list box.

Under the "Averages" tab when selecting a function name from the "Child Calls" listbox the wrong function is highlighted in the main "Functions" listbox. However, it does bring up the correct source code and shows the correct list of "Called From" functions - so it seems to know the right function being selected, just not the updated listbox entry index in the main Functions listbox. The same problem occurs when selecting a function from the list in the "Call Stacks" tab.

This does not happen when I have not enabled any filters, so it seems that it's simply ignoring all the functions that were filtered out as the function it does highlight in the main Functions listbox is always after the correct function, which to my mind indicates that the index is assuming the list is larger than what's being shown.

This happens in both the 32 and 64 bit versions on my Windows 7 64-bit desktop - haven't tested on any other machines yet.

Otherwise VerySleepy is great! Thanks!

Invalid full path handling

An example in Source window:
[ Could not open file 'G:\m_proj/G:/QT/Tools/mingw482_32/i686-w64-mingw32/include/c++/bits/shared_ptr_base.h'. ]
Looks like full path not handled right way

Is "HELP" missing ???

When I click on the "HELP" button, the only item in the drop down menu is an "About" button.

Is there supposed to be anything else?

I note that there is a 'dbghelpms.dll" and a "dbghelpw.dll" dll in the "C:\Program Files\Very Sleepy CS" folder.

-- Thanks,
-- Paul Townsend

highlight selected call stack line in source display

it would be nice if the current selected frame/line in the call stack display, was highlighted in the source panel.
i.e. with a slightly different shade of background color on that line

Loading symbols from an incremental PDB

Hi,

When you have incremental linking enabled (/INCREMENTAL) and maybe /DEBUG:FASTLINK, VerySleepy cannot load the symbols at all, so only function addresses are displayed. Could there be an improvement for this?

Sometimes it's just necessary to profile a debug build, and incremental linking saves a lot of compilation/linking time.

can't run sleepy from command line with arguments in msys2

When I try running sleepy from the command line with arguments in msys2, I get an error:

$ sleepy /r:a.exe

The same thing happens if I surround a.exe with quotes.

Even running sleepy /h fails:

Though it is a little revealing, because something turned "/h" into "H:"

If instead I call "cmd", and have it run sleepy, everything works:
cmd /C "sleepy /r:a.exe"

And I can pass program arguments like:
cmd /C "sleepy /r:\"a.exe foo\""

I tested it from cygwin, and cygwin is able to run sleepy fine directly, without needing to go through cmd.

I'm installed msys2 from msys2-x86_64-20141113.exe and I have windows 7.

See call counts?

First of all, I love this profiler; its lean and gets the job done, unlike vTune and VS Performance Explorer. However, where are the call counts? I'd like to know the number of samples each function received, in its own column in the main panel. This is important for comparing runs after making changes.

Is the information there and I'm just not seeing it? Or is it not there and impossible to report?

No start on Win 8.1 x64

---

sleepy.exe - Entry point not found

SetCheckUserInterruptShared not found in DLL C:\Windows\SYSTEM32\dbgeng.dll.

Allow creating new profile from the result window

asegura on reddit writes:

One thing I remember as a bit cumbersome: Once you select a process to profile, you cannot go back to the process list to re-profile the same process or a different one. You have to exit and restart VS, IIRC.

Windows 10, can't resolve mingw executable symbols

Hi,

I tried to use sleepy on emacs.exe compiled with mingw64. Sleepy is displaying statistics, but is not able to resolve symbols :

Any hint on how to solve this ?

I have compiled sleepy myself from sources.

Thanks,

(And BTW I'm impressed by sleepy !)

Switch to Visual Studio Community 2017

Using Visual Studio 2010 has the following problems:

• It is not freely available from Microsoft. This makes it harder, for some people even impossible, to contribute to VerySleepy.
• It does not support modern C++

Visual Studio Community 2017 on the other hand is

• Free to download for everyone here: https://www.visualstudio.com/downloads/
• Has good support for C++ 11, 14 and 17: https://blogs.msdn.microsoft.com/vcblog/2017/05/10/c17-features-in-vs-2017-3/

The trunk version of WxWidgets compiles fine with VS 2017 using wx_vc15.sln

If support for Windows XP is absolutely required, there still seems to be a compatible toolset v141_xp in VS 2017.

How can we profile all the threads(dynamic threads also)?

I have an application while performing the workflow I come across some dynamic threads.I wanted to know changes we need to make so that it can profile dynamic threads also .I was looking at sampleTarget() method of profiler.cpp file.Is it the right place to fix this problem?

Add filter by thread

Currently, when multiple threads are selected for a profiling session, stats are displayed as an aggregate for all threads. When trying to profile a task system for example, you don't know in advance which thread will pick up the workload you're interested in profiling, so you can't select it beforehand.
The ability to filter by thread would alleviate the issue.

Needs to do actual CPU usage profiling

Maybe I'm missing something, but as I understand it, VS takes almost-continuous snapshots of the stack in all/some of the threads in a Windows process. This is extremely helpful, but it doesn't directly indicate which functions are actually responsible for CPU usage, since some of the functions at the bottom of the stack block.

But there are a small, fixed number of functions that block in the Windows libraries. Why can't VS have a list of them, perhaps extensible by the user? The blockers would be interpreted as using zero CPU. Then, VS would be able to declare that any stack trace that doesn't end in a blocker is using CPU, and actually list the functions and their CPU usage....

Could not load dbghelpdr.dll

I get this error when launching 0.91 on Windows Vista 32bit.

I downloaded DrMinGW 0.9.1 (also tried 0.9.2) and copied mgwhelp.dll into the Sleepy install folder + renamed it to dbghelpdr.dll, but I still get the same error.

Is there any way around this issue?
Thanks.

symbols and responsiveness on selecting a process

I set up symbols and it works fine in general.

But selecting a different process in the "Select a process to profile" suddenly became a rather lengthy procedure. From the initial wait on all the DBGHELP / SYMSRV shenanigans (5 - 10s, depending on latency to symbol server I guess) to a "Not Responding" window to an eventual hang or refresh it really gets in my way (20s in total) when I am more focused on profiling the startup of a certain process.

I don't want to give up symbolication yet and there is obviously ways around this behavior (suspending process in Process Explorer or have a wait loop in your code) but I wonder if this symbol loading for the translation can't be done in a more lazy / deferred way?
I really would love the list to be more responsive, i.e. selecting a newly spawned process has no delay and just cancels what it is currently doing ...

Add a "Visits" column to all function lists

For the call stack and callers view, 'Visits' specifies the number of entries to a given function.

It may help to profile functions with the same exclusive/inclusive time, but different entries number.

cannot find dbghelpdr.dll from a recent binary release of Very Sleepy

According to the readme.md:

If you do not want to build Dr. MinGW's DbgHelp from source, you can place dbghelpdr.dll from a recent binary release of Very Sleepy (or Dr. MinGW, where it will be called mgwhelp.dll) into the dbghelp_x86 and dbghelp_x64 directories appropriately.

But I cannot find dbghelpdr.dll from a recent binary release of Very Sleepy (0.90, nor 0.82)

Error: ProfilerExcep: ResumeThread failed.

I have this message box:
Error: ProfilerExcep: ResumeThread failed.

I try to profile NT Service, 32 bit process, an run profiles at administrator rights.

How can I help to collect more information?

Very Sleepy doesn't profile C++ dll loaded by a .NET exe.

Thank you for this simple yet very powerful tool. It helps a lot.

Ok now, What I mean is that the profiling information doesn't show the function names and modules of my C++ dlls when they are launched by a .NET exe. Very Sleepy could locate the pdbs too.

Do we have any support or recommendations for this scenario?

Installer blocked by antivirus

Avira says it contains unwanted program HEUR/APC (Cloud).

Debug symbols are wrong/mixed up with MinGW/GCC 8.1.0 compiled program.

I've a project that when compiled using MinGW/GCC v3.4.5 with -g1 Very Sleepy works fine profiling it: functions are accurate and clicking one brings up its source code.

However, compiling the exact same project, using MinGW/GCC v8.1.0 it took a bit of wrangling but I finally managed to get Very Sleepy to see the symbols (the whole time it would say that it had loaded DWARF debugging symbols but functions would show up as their addresses). This required -g0 -dwarf-
2 -fno-omit-frame-pointer before I could see symbols.

The problem is that the symbols are wrong! Function names are showing up for functions which definitely are not executing during profiling, I know this to be fact because the functions require a very specific path of user interaction and they are only executed sparingly and never to the point where they would make up a significant portion of the exclusive execution time. I know for a fact the functions named are not the actual ones executing as Very Sleepy very obviously shows the actual functions executing when compiled with GCC v3.4.5. I know that GCC changed some things with debugging symbols since one of the more recent versions, but Very Sleepy seems to be completely unusable with these newer versions of GCC as a direct result. Also, I have not been able to get symbols to work at all when compiling 64-bit, even with the compiler flags that kinda work for the 32-bit version of 8.1.0.

Also, clicking on a function fails to bring up the source file at all, let alone the function's source code - and for the source file path in the status bar it shows the source code filepath as being it's absolute path with a copy of the absolute path appended to that - except with the slashes inverted.

I'm super bummed about this, because Very Sleepy was the perfect profiling option for a long time and I only changed compiler versions to keep with the times as my project needed to be able to access more memory and I could only do that by compiling 64-bit with a newer version of MinGW/GCC. I really hope this can be resolved at some point in the near future.

Provide a way to monitor "cycles"

e.g. some standard way we can expose a counter in the code being profiled, and an option to profile for N iterations, or until a particular variable gets a given value.

This would make it simpler to compare subsequent runs over the same code (e.g. optimising loops)

support for mingw-w64

Using very sleepy with mingw-w64 x86 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-posix/dwarf/ leads to a crash.

Using very sleepy with mingw-w64 x64 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.9.1/threads-posix/seh/
works but the symbols aren't resolved.

Doesn't seem to support the VC140 compiler

The function names are not resolved...

Very Sleepy could not profile DLL when issuing from command line

We use correct /r"test.exe" to do the job.
We use Very Sleepy newest version.
The test.exe will load a dll, which is called test2.dll. The DLL is dynamically loaded, and released before test.exe exit.

Functions inside test.exe could be got correctly. But the functions inside DLL only show binary address.
The PDBs of exe/dll are all in current directory, and Very Sleepy could show correct function name if use attach method.

This is very important, since coders could use such command line interface to easily implement a small regression system for performance reports. What's more, no need to attach a process not only ease the work, but also show correct info from the very beginning.

Website link broken

Help > About... > View Sleepy web site
Gives a 404.

Add API to start/stop profiling programmatically

It would be helpful to have a way of starting and stopping profiling programmatically, to have more control over what was being profiled.

There is an old attempt to do this at https://github.com/mhoffesommer/Very-Sleepy. Did this approach work? Could it be added to the current codebase?

Can we export the profiling data as .CSV in command line mode?

I was using this software to profile one of my C++ component.It comes really handy in UI mode.But I wanted to run the process in the background and give me the details in .CSV format.As of now I able to generate a .slpeey file in command mode .How can I generate .CSV?

stack frame % in call stack display

when displaying the call stack panel, it would be very helpful if at each level of the call stack, there was a "no of times seen" count.

i.e. I want to know how times the sampler saw that frame in the call stack.

I'm expecting, for example, that the frame at the bottom (main) would be seen all the time (i.e. 100%) and the frame at the top would be seen the same percentage as the call stack percentage.

What I'm trying to extract is what part of the call stack is common to the entire period of time the sampler was running, and what part of the call stack is unique to this particular call stack.

Thanks for a great tool! Hope there will be a new release soon!

Question: any directions on use the profiling core of verysleepy as API

Is it feasible to do the profiling programmatically in my own c++ application? Thanks!

Does VerySleepy support static code profiling?

1、pull an engineering code to local on github
2、Analyze it through Very Sleepy.However, Very Sleepy can open individual specific files, and cannot open the entire file for analysis.

Profiler Exeption

Hello,
somtimes profiler throw error "Error: ProfilerExcep: GetThreadContext failed." and exit.
And I cannot get result.

New threads created during profiling get ignored

If new threads are created during profiling, and you're using the "Profile All" option in the frontend, these new threads get ignored.

The app should either auto attach to any new threads when this is used, or provide an option to do so

New Release?

Why has there been no release for more than 2 years?
While I can find much praise for Very Sleepy online, the one reoccurring complaint I find is related to resolving symbols. I noticed that significant improvements have been made on this front and am wondering why people have to go through the effort of compiling to get these features.
Thanks!

Use stable sort for sorting columns in all functions list to preserve previous sort order

It may help to sort by time within modules.
For example, we can have time in descending order within modules.

       Time     Module
Foo1    2.1      kernel32
Foo2    1.9      kernel32
Foo3    5.3      mydll
Foo4    4.7      mydll

File -> Export as CSV improvement

First line of CSV file should contain names of columns (name1,name2,name3,blabla), so you know what data goes below instead of guessing.

Child Calls time distribution misleading

I am a VerySleepy user. The program is invaluable but it has one bug which annoys me a lot.

The Child Calls window shows wrong values in Samples and %Calls columns. The problem here is exclusive time (spent in function body itself) is not shown anywhere so one of the child calls (first one?) is artificially increased probably because of matching total time with sum of all child calls. That is very misleading especially when inspected function has significant exclusive time.

I propose to add another line to the listbox for exclusive time.

What Visual Studio 2019 C++ settings work with VerySleepy? (No source files showing)

Those are my current settings for x64 debug mode, or will it only work in x86 mode?

And all the other settings, what do they have to be?

Because I'm currently getting no source file showing for any of my executables line in the profiler % results.

Investigate CMake build support

It may be of use to add CMake build support.

This would allow all versions of VisualStudio+MinGW to be compiled for, rather then having a single (older) checked in visual studio solution. CMake is not perfect by any means but it may be of use in this situation, and could live along side the visual studio solution for some time.

Thoughts?