Visual Python and C++ nanosecond profiler, logger, tests enabler

Overview

Look into Palanteer and get an omniscient view of your program

Build Status

Palanteer is a set of lean and efficient tools to improve the quality of software, for C++ and Python programs.

Palanteer viewer image

Simple code instrumentation, mostly automatic in Python, delivers powerful features:

  • Collection of meaningful atomic events on timings, memory, locks wait and usage, context switches, data values..
  • Efficient logging with a printf-compatible interface
  • Visual and interactive observation of records: hierarchical logs, timeline, plot, histogram, flame graph...
  • Remote command call and events observation can be scripted in Python: deep testing has never been simpler
  • C++:
  • Python:
    • Automatic instrumentation of functions enter/leave, memory allocations, raised exceptions, garbage collection runs
    • Seamless support of multithreading, asyncio/gevent

Recording simultaneously up to 8 streams (i.e., from different processes) is supported.

Palanteer is an efficient, lean and comprehensive solution for better and enjoyable software development!

C++ instrumentation example

Below is a simple example of a C++ program instrumented with Palanteer and generating 100 000 random integers. The range can be remotely configured with a user-defined CLI.

The Python scripting module can control this program, in particular:

  • call the setBoundsCliHandler to change the configuration
  • temporarily stop the program at the freeze point
  • see all "random data" values and the timing of the scope event "Generate some random values"
See C++ example code
// File: example.cpp
// On Linux, build with:  g++ -DUSE_PL=1 -I <palanteer C++ instrumentation folder> example.cpp -lpthread -o example
#include <stdlib.h>          // For "rand"
#define PL_IMPLEMENTATION 1  // The instrumentation library shall be "implemented" once
#include "palanteer.h"

int globalMinValue = 0, globalMaxValue = 10;

// Handler (=user implementation) of the example CLI, which sets the range
void setBoundsCliHandler(plCliIo& cio)             // 'cio' is a communication helper passed to each C++ CLI handler
{
    int minValue = cio.getParamInt(0);             // Get the 2 CLI parameters as integers (as declared)
    int maxValue = cio.getParamInt(1);
    if(minValue>maxValue) {                        // Case where the CLI execution fails. The text answer contains some information about it
        cio.setErrorState("Minimum value (%d) shall be lower than the maximum value (%d)", minValue, maxValue);
        return;
    }

    // Modify the state of the program. No care about thread-safety here, to keep the example simple
    globalMinValue = minValue;
    globalMaxValue = maxValue;
    // CLI execution was successful (because no call to cio.setErrorState())
}


int main(int argc, char** argv)
{
    plInitAndStart("example");              // Start the instrumentation, for the program named "example"
    plDeclareThread("Main");                // Declare the current thread as "Main" so that it can be identified more easily in the script
    plRegisterCli(setBoundsCliHandler, "config:setRange", "min=int max=int", "Sets the value bounds of the random generator");  // Declare our CLI
    plFreezePoint();                        // Add a freeze point here to be able to configure the program at a controlled moment

    plBegin("Generate some random values");
    for(int i=0; i<100000; ++i) {
        int value = globalMinValue + rand()%(globalMaxValue+1-globalMinValue);
        plData("random data", value);       // Here are the "useful" values
    }
    plEnd("");                              // Shortcut for plEnd("Generate some random values")

    plStopAndUninit();                      // Stop and uninitialize the instrumentation
    return 0;
}

Some C++ performance figures (see here for more details):

  • nanosecond resolution and ~25 nanoseconds cost per event on a standard x64 machine
  • up to ~5 millions events per second when recording, bottleneck on the server processing side
  • up to ~150 000 events per second when processing the flow through a Python script, bottleneck on the Python script side

Python instrumentation example

Execution of unmodified Python programs can be analyzed directly with a syntax similar to the one of cProfile, as a large part of the instrumentation is automated by default:

  • Functions enter/leave
  • Interpreter memory allocations
  • All raised exceptions
  • Garbage collection runs
  • Coroutines

In some cases, a manual instrumentation which enhances or replaces the automatic one is desired.
The example below is an equivalent of the C++ code above, but in Python:

See Python manual instrumentation example code
#! /usr/bin/env python3
import sys
import random
from palanteer import *

globalMinValue, globalMaxValue =  0, 10

# Handler (=implementation) of the example CLI, which sets the range
def setBoundsCliHandler(minValue, maxValue):              # 2 parameters (both integer) as declared
    global globalMinValue, globalMaxValue
    if minValue>maxValue:                                 # Case where the CLI execution fails (non null status). The text answer contains some information about it
        return 1, "Minimum value (%d) shall be lower than the maximum value (%d)" % (minValue, maxValue)

    # Modify the state of the program
    globalMinValue, globalMaxValue = minValue, maxValue
    # CLI execution was successful (null status)
    return 0, ""


def main(argv):
    global globalMinValue, globalMaxValue

    plInitAndStart("example")                             # Start the instrumentation
    plDeclareThread("Main")                               # Declare the current thread as "Main", so that it can be identified more easily in the script
    plRegisterCli(setBoundsCliHandler, "config:setRange", "min=int max=int", "Sets the value bounds of the random generator")  # Declare the CLI
    plFreezePoint()                                       # Add a freeze point here to be able to configure the program at a controlled moment

    plBegin("Generate some random values")
    for i in range(100000):
        value = int(globalMinValue + random.random()*(globalMaxValue+1-globalMinValue))
        plData("random data", value)                      # Here are the "useful" values
    plEnd("")                                             # Shortcut for plEnd("Generate some random values")

    plStopAndUninit()                                     # Stop and uninitialize the instrumentation

# Bootstrap
if __name__ == "__main__":
    main(sys.argv)

Scripting example

Both examples above (C++ and Python) can be remotely controlled with a simple Python script.

Typical usages are:

  • Tests based on stimulation/configuration with CLI and events observation, as data can also be traced
  • Evaluation of the program performance
  • Monitoring
  • ...
See a scripting example code (Python)
#! /usr/bin/env python3
import sys
import palanteer_scripting as ps

def main(argv):
    if len(sys.argv)<2:
        print("Error: missing parameters (the program to launch)")
        sys.exit(1)

    # Initialize the scripting module
    ps.initialize_scripting()

    # Enable the freeze mode so that we can safely configure the program once stopped on its freeze point
    ps.program_set_freeze_mode(True)

    # Launch the program under test
    ps.process_launch(sys.argv[1], args=sys.argv[2:])
    # From here, we are connected to the remote program

    # Configure the selection of events to receive
    my_selection = ps.EvtSpec(thread="Main", events=["random data"]) # Thread "Main", only the event "random data"
    ps.data_configure_events(my_selection)

    # Configure the program
    status, response = ps.program_cli("config:setRange min=300 max=500")
    if status!=0:
        print("Error when configuring: %s\nKeeping original settings." % response)

    # Disable the freeze mode so that the program resumes its execution
    ps.program_set_freeze_mode(False)

    # Collect the events as long as the program is alive or we got some events in the last round
    qty, sum_values, min_value, max_value, has_worked = 0, 0, 1e9, 0, True
    while ps.process_is_running() or has_worked:
        has_worked = False
        for e in ps.data_collect_events(timeout_sec=1.):  # Loop on received events, per batch
            has_worked, qty, sum_values, min_value, max_value = True, qty+1, sum_values+e.value, min(min_value, e.value), max(max_value, e.value)

    # Display the result of the processed collection of data
    print("Quantity: %d\nMinimum : %d\nAverage : %d\nMaximum : %d" % (qty, min_value, sum_values/max(qty,1), max_value))

    # Cleaning
    ps.process_stop()            # Kills the launched process, if still running
    ps.uninitialize_scripting()  # Uninitialize the scripting module


# Bootstrap
if __name__ == "__main__":
    main(sys.argv)

The execution of this last script, with the compile C++ as parameter, gives the following output:

> time ./remoteScript.py example
Quantity: 100000
Minimum : 300
Average : 400
Maximum : 500
./remoteScript.py example  0.62s user 0.02s system 24% cpu 2.587 total

Details can be found here.

Logging

Logs are timestamped printf-like messages that contain a severity level and a category for easier filtering.

Nanosecond efficiency is reached by leveraging compile-time pre-computations and deferring formatting on the viewer side.
Console display can also be enabled dynamically, for easy local debugging.

Example:

plLogDebug("input", "Key '%c' pressed", pressedKeyChar);

plLogInfo("computation result", "The resulting value of the phase %-20s is %g with the code 0x%08x",
          phaseStr, floatResult, errorCode);

plLogWarn("phase", "End of a computation");

An internal comparison with the popular spdlog and the performant Nanolog (Standford) shows thatPalanteer:

  • is ~50x faster at runtime than spdlog and only twice slower than Nanolog
  • is 6x faster for compiling a log call than spdlog and 10x faster than Nanolog
  • provides more flexibility on the log selection at compile time, and the possibility to obfuscate all static strings.
  • can provide more context around logs, like simultaneous tracing, and a powerful viewer for filtering and visualizing (all log arguments can be graphed)

Documentation

The complete documentation is accessible inside the repository, and online:

OS Support

Viewer and scripting library:

  • Linux 64 bits
  • Windows 10

Instrumentation libraries:

  • Linux 32 or 64 bits (tested on PC and armv7l)
  • Windows 10
  • Support for virtual threads
    • in C++ (userland threads, like fibers)
    • in Python (asyncio / gevent)

Requirements

Palanteer is lean, its full installation requires only usual components:

  • a C++14+ compiler (gcc, clang or MSVC) in Windows 10 or Linux 64 bits for the viewer and scripting module
  • a C++11+ compiler (tested with gcc, clang and MSVC) 32 or 64 bits for the C++ instrumentation library
  • CPython 3.7+
  • OpenGL 3.3+

In particular, the C++ single-header instrumentation library requires only C++11 or above.

See here for more details on the requirements per component.

Other dependencies are snapshotted inside this repository, so for information only:

Dependency name License type URL
Khronos OpenGL API and Extension MIT https://www.khronos.org/registry/OpenGL/api/GL
Dear ImGui MIT https://github.com/ocornut/imgui
stb Public domain https://github.com/nothings/stb
Fonts 'Roboto-Medium.ttf' Apache License, Version 2.0 https://fonts.google.com/specimen/Roboto
ZStandard BSD https://facebook.github.io/zstd
Markdeep BSD https://casual-effects.com/markdeep

License

The instrumentation libraries are under the MIT license.

The viewer and the Python scripting module are under the AGPLv3+.

See LICENSE.md for details.

Warning: Beta state

Even if no major bugs are known and special care has been taken to test as many cases as possible, this project is young and in beta state.

Your feedback and raised issues are warmly welcome to improve its quality, especially as it aims at improving software quality...

The state of the "interfaces" is:

  • Instrumentation API: stable, no big changes planned
  • Client-server protocol: still evolving. The induced constraint is that the servers and instrumentation libraries shall match.
  • Record storage: still evolving. The impact of compatibility breaks is that older records cannot be read anymore.

Interface stability and support of older versions is planned when the project is more mature. At the moment, such constraint would clamp down on its evolution.

Comments
  • Crash when trying to instrument a program on current git master

    Crash when trying to instrument a program on current git master

    Linux x64: as soon as I launch the app to profile, the GUI crashes with:

    [PALANTEER] Assertion failed: _underRecordRecIdx>=0
      On function: void vwMain::draw()
      On file    : /home/jcelerier/projets/perso/lafajol/3rdparty/palanteer/server/viewer/vwMain.cpp(357)
        - int     _underRecordRecIdx   = -1
    
      #0  0x55AE269C7652 : _ZN6vwMain4drawEv
      #1  0x55AE26A59C37 : _ZN10vwPlatform6redrawEv
      #2  0x55AE26A59D29 : _ZN10vwPlatform3runEv
      #3  0x55AE26A5A80B : _Z11bsBootstrapiPPc
      #4  0x7F560497130C : __libc_start_call_main
      #5  0x7F56049713BD : __libc_start_main@@GLIBC_2.34
      #6  0x55AE269449D1 : _start
    
    opened by jcelerier 15
  • Possible race condition leading to access to NULL pointer

    Possible race condition leading to access to NULL pointer

    This might have been partly due to overflow, as I saw buffer saturation previously. Either case, the race condition seems to be there.

    On commit: fd6a6a3e0914eae579216ab43793bd5dc62c53cf Compiler: gcc 9.3.0 with -g -O0 --std=c++20 You can hopefully reproduce it using the exact code, though I haven't exhaustively tested it (should work on x86_64, but who knows, it's way too hacky right now). https://github.com/NetPunkSoftware/Fibers/commit/405d493cf4199a0b34a966b86a6a51def8417f0f

    It happens about 3 out of every 5 executions.


    Now, into what I believe is a race condition. See the following two stack traces:

    Thread 1:

    plPriv::hashString(const char * s, int maxCharQty) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1460)
    plPriv::collectEvents(bool doForce) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:3485)
    plPriv::transmitToServer() (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:3874)
    std::__invoke_impl<void, void (*)()>(void (*&&)(void) __f) (/usr/include/c++/11/bits/invoke.h:61)
    std::__invoke<void (*)()>(void (*&&)(void) __fn) (/usr/include/c++/11/bits/invoke.h:96)
    std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul>(std::thread::_Invoker<std::tuple<void (*)()> > * const this) (/usr/include/c++/11/bits/std_thread.h:253)
    std::thread::_Invoker<std::tuple<void (*)()> >::operator()(std::thread::_Invoker<std::tuple<void (*)()> > * const this) (/usr/include/c++/11/bits/std_thread.h:260)
    std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run(std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > > * const this) (/usr/include/c++/11/bits/std_thread.h:211)
    libstdc++.so.6![Unknown/Just-In-Time compiled code] (Unknown Source:0)
    libpthread.so.0!start_thread(void * arg) (/home/build/YPKG/root/glibc/build/glibc.git/nptl/pthread_create.c:481)
    libc.so.6!clone() (/home/build/YPKG/root/glibc/build-avx2/glibc.git/sysdeps/unix/sysv/linux/x86_64/clone.S:95)
    

    Particularly plPriv::collectEvents at palanteer-src/c++/palanteer.h:3485. The current even being iterated, src, points to 0x7ffff70af990.

    Other variables of possible interest (at collectEvents):

    evtIdx = 12901
    eventQty = 20036
    globalCtx.prevBankAndIndex = 20036
    

    Now, Thread 2:

    plPriv::eventLogBase(uint32_t bi, plPriv::hashStr_t filenameHash_, plPriv::hashStr_t nameHash_, const char * filename_, const char * name_, int lineNbr_, int flags_) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1545)
    plPriv::eventLogRaw(plPriv::hashStr_t filenameHash_, plPriv::hashStr_t nameHash_, const char * filename_, const char * name_, int lineNbr_, bool doSkipOverflowCheck_, int flags_, plPriv::bigRawData_t v) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1565)
    plPriv::TimedScope::~TimedScope(plPriv::TimedScope * const this) (/home/guillem/Github/Fibers/build/_deps/palanteer-src/c++/palanteer.h:1825)
    np::fiber_pool_base::worker_thread(np::fiber_pool_base * const this, uint8_t idx) (/home/guillem/Github/Fibers/src/pool/fiber_pool.cpp:171)
    std::__invoke_impl<void, void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int>(std::__invoke_memfun_deref, void (np::fiber_pool_base::*&&)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*&&, int&&)(void (np::fiber_pool_base::*&&)(np::fiber_pool_base * const, unsigned char) __f, np::fiber_pool<np::detail::default_fiber_pool_traits> *&& __t) (/usr/include/c++/11/bits/invoke.h:74)
    std::__invoke<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int>(void (np::fiber_pool_base::*&&)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*&&, int&&)(void (np::fiber_pool_base::*&&)(np::fiber_pool_base * const, unsigned char) __fn) (/usr/include/c++/11/bits/invoke.h:96)
    std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> >::_M_invoke<0ul, 1ul, 2ul>(std::_Index_tuple<0ul, 1ul, 2ul>)(std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > * const this) (/usr/include/c++/11/bits/std_thread.h:253)
    std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> >::operator()()(std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > * const this) (/usr/include/c++/11/bits/std_thread.h:260)
    std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > >::_M_run()(std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (np::fiber_pool_base::*)(unsigned char) noexcept, np::fiber_pool<np::detail::default_fiber_pool_traits>*, int> > > * const this) (/usr/include/c++/11/bits/std_thread.h:211)
    libstdc++.so.6![Unknown/Just-In-Time compiled code] (Unknown Source:0)
    libpthread.so.0!start_thread(void * arg) (/home/build/YPKG/root/glibc/build/glibc.git/nptl/pthread_create.c:481)
    libc.so.6!clone() (/home/build/YPKG/root/glibc/build-avx2/glibc.git/sysdeps/unix/sysv/linux/x86_64/clone.S:95)
    

    The last call, plPriv::eventLogBase, at palanteer-src/c++/palanteer.h:1545, is writing an event. Uppon inspection, e has the same address 0x7ffff70af990. It has crashed short of writing the string itself, which would have been the next line. At the moment of the crash, e.nameHash == 0 and e.name == 0.

    Other variables of possible interest (at eventLogBase):

    bi = 12901
    

    If this is caused due to me going well beyond the acceptable buffer size, maybe we could introduce some assertion during debug, so that it triggers instead of causing UB.

    Otherwise, I see two ways of going over this:

    1. Adding a local ready atomic to each event, so that the consumer must spin/yield until it is flagged by the producer.

    2. Using two pointers to the buffer, so that one points to the last valid position (ie. written and valid) and the another one points to the last writable position (ie. free and not being used).

    bug C++ instrumentation 
    opened by gpascualg 7
  • Consistent crashes when navigating to some directories with the import file dialog

    Consistent crashes when navigating to some directories with the import file dialog

    Here, https://github.com/dfeneyrou/palanteer/blob/main/server/viewer/vwFileDialog.cpp#L203-L204

    I consistently get a EXC_I386_GPFLT (general protection fault) on a.name.toChar() when navigating to certain directories. I can iterate and print the names of all elements in _fileEntries without issue, so I imagine that std::sort is doing something undesirable in conjunction with your string library. Unfortunately I'm not really sure how best to debug this issue, and I haven't found anything particularly special about the failing directories.

    bug 
    opened by jceipek 6
  • Error: unable to check the elem MR non increasing speck in Python's testprogram collect

    Error: unable to check the elem MR non increasing speck in Python's testprogram collect

    First of all, thanks a million for your work on this. I'm just playing around with Palanteer and I am getting the following error when trying to collect data with the Python example:

    python/testprogram/testprogram.py collect
    Mode 'connected'
    Statistics:
      Execution time: 1659 ms
    

    image

    I get it every single time this or any other app finishes. After that, I can't use the saved trace anymore. I can only work commenting out the check in cmRecord.cpp, even though I know this is not right, it's the only way I can use the tool:

    // for(int i=0; i<curArray.size(); ++i) {
    //     if(curArray[i].speckUs>upperArray[i/cmMRElemSize].speckUs) LOAD_ERROR("check the elem MR non increasing speck");
    // }
    

    Here's the file that is collected by the viewer, in case it's useful. When trying to open it with the viewer, I get the already mentioned error Python testcollect.zip

    This happens both in v0.6 and in main. It happens on every single Python application I've tested once it finishes. In case it's useful, some info about my system:

    Ubuntu 20.04
    g++ 9.3.0
    Python 3.8.10
    

    Again, thanks a lot for this tool and for your time taking a look at this issue.

    bug question 
    opened by pamarcos 5
  • MSVC 2022: C++ library build broken with UNICODE

    MSVC 2022: C++ library build broken with UNICODE

    When trying to build the c++ library while having UNICODE declared, the following error occurs:

    palanteer-src\c++\palanteer.h(4346,53): error C2440: '=': cannot convert from 'const wchar_t [17]' to 'LPWSTR'
    

    Basically, in that line, LogFile.LoggerName = KERNEL_LOGGER_NAME; the structure field expects a non-const value, while KERNEL_LOGGER_NAME is const. I have worked around it by casting it to (LPWSTR). I don't know the API exactly, so it feels like a hack to cast it to non-constness.

    - LogFile.LoggerName          = KERNEL_LOGGER_NAME;
    + #if defined(_UNICODE) || defined(UNICODE)
    + LogFile.LoggerName          = (LPWSTR)KERNEL_LOGGER_NAME;
    + #else
    + LogFile.LoggerName          = KERNEL_LOGGER_NAME;
    + #endif
    
    bug question C++ instrumentation 
    opened by gpascualg 5
  • unexpected app shutdown

    unexpected app shutdown

    I have a big profiling data file > 1gb. After loading application hangs and closes. Reproducibility 100%

    [https://transfer.pcloud.com/download.html?code=5ZELnbVZ6rcgA5EfxkFZLzoUZkVrHCBRnHrLtwaNHIHgEQm8jksKy](profile data)

    opened by italiks 4
  • MSVC 2022: Run-Time Check Failure #3 - The variable 'prevE' is being used without being initialized.

    MSVC 2022: Run-Time Check Failure #3 - The variable 'prevE' is being used without being initialized.

    Checked out at: e305d17585eb2188896ed0c2d7cc0913947dd399

    When zooming a timeline in, either in a live view or record that uses fibers, visual studio complains of an access to an initialized variable.

    palanteer.exe!vwMain::prepareTimeline(vwMain::Timeline & tl) Line 1150 C++ palanteer.exe!vwMain::drawTimeline(int tlWindowIdx) Line 1478 C++ palanteer.exe!vwMain::drawTimelines() Line 1432 C++ palanteer.exe!vwMain::draw() Line1149 C++ palanteer.exe!vwPlatform::redraw() Line 365 C++ palanteer.exe!vwPlatform::run() Line 304 C++ palanteer.exe!bsBootstrap(int argc, char * * argv) Line 200 C++ palanteer.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, wchar_t * lpCmdLine, int nCmdShow) Line 780 C++

    I would submit a PR (proposed change at the bottom), but I suspect there is something more, as by the looks of it and the variable name, prevE should probably never be used during the first iteration.

    vwMainTimeline.cpp:1138

    - cmRecord::Evt prevE, e; prevE.nameIdx = PL_INVALID;
    + cmRecord::Evt prevE, e; prevE.nameIdx = PL_INVALID; prevE.flags = 0x0;
    
    bug viewer 
    opened by gpascualg 4
  • Python multiprocessing support

    Python multiprocessing support

    Hello,

    I've traced a Python application that uses multiprocessing. The way the processes are started is like this:

    • main process running a PySide6 GUI
      • secondary process started from the main process
        • after some user configuration the secondary process starts several child processes

    I can only see the main process trace information.

    Is there something that I'm missing?

    opened by danielhrisca 2
  • How to start service (so thread/fiber registration works) but not start recording yet?

    How to start service (so thread/fiber registration works) but not start recording yet?

    I've been trying the fiber integration as per your helpful Gist from a while back (https://gist.github.com/dfeneyrou/8f8aa2956dcb32e0860665c610d7bb2f).

    I was following my usage pattern of Optick, where I didn't start profiling from the beginning but instead triggered it via a debug menu. However, my FTL Task Scheduler is created at the beginning, and its creation invokes the callbacks shown in the above Gist. Because of this, the calls to e.g. plDeclareVirtualThread take place before the call to plInitAndStart, and so in the profiler itself none of that information is shown.

    Am I able to somehow start up the service at the beginning so that these registrations are accepted, but not start any kind of recording / transmission to the Palanteer application until later? I know there's PL_MODE_INACTIVE, but as far as I can see, the mode can't be changed after the init call?

    I'll have to try calling plInitAndStart at game start, creating my scheduler and having the FTL callbacks fire, then immediately calling plStopAndUninit, and then calling init again later when I want to actually profile. Bit messy though and not sure if it works right.

    EDIT: Looks like init-stop-init isn't the solution; not surprised.

    image

    bug enhancement 
    opened by BrodyHiggerson 2
  • Make `pip install palanteer` possible

    Make `pip install palanteer` possible

    Hello guys,

    Thanks for your contribution. palanteer seems really cool. I have to give it a shot to see what it has to offer.

    I am proposing that you would consider publishing your package in the PyPi registry so that python developers would be able to install it using pip.

    Keep up the good work and stay awesome. 🥂

    opened by meysam81 2
  • Building broken on Linux - permission denied

    Building broken on Linux - permission denied

    [email protected] ~/g/p/build (main) [1]> cmake .. -DCMAKE_INSTALL_PREFIX=/opt/palanteer
    -- The C compiler identification is GNU 9.3.0
    -- The CXX compiler identification is GNU 9.3.0
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working C compiler: /usr/bin/cc - skipped
    -- Detecting C compile features
    -- Detecting C compile features - done
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /usr/bin/c++ - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    Build type: Release   (change with -DCMAKE_BUILD_TYPE=<Debug|Release|RelWithDebInfo|MinSizeRel|Asan>)
    -- Looking for pthread.h
    -- Looking for pthread.h - found
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
    -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
    -- Check if compiler accepts -pthread
    -- Check if compiler accepts -pthread - yes
    -- Found Threads: TRUE  
    -- Found OpenGL: /usr/lib/x86_64-linux-gnu/libOpenGL.so   
    -- Found X11: /usr/include   
    -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
    -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
    -- Looking for gethostbyname
    -- Looking for gethostbyname - found
    -- Looking for connect
    -- Looking for connect - found
    -- Looking for remove
    -- Looking for remove - found
    -- Looking for shmat
    -- Looking for shmat - found
    -- Looking for IceConnectionNumber in ICE
    -- Looking for IceConnectionNumber in ICE - found
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBUNWIND)
      does not match the name of the calling package (LibUnwind).  This can lead
      to problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibUnwind.cmake:23 (find_package_handle_standard_args)
      server/viewer/CMakeLists.txt:29 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    -- Found LIBUNWIND: /usr/lib/x86_64-linux-gnu/libunwind.so  
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBDW) does
      not match the name of the calling package (LibDw).  This can lead to
      problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibDw.cmake:23 (find_package_handle_standard_args)
      server/viewer/CMakeLists.txt:30 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    -- Found LIBDW: /usr/lib/x86_64-linux-gnu/libdw.so  
    Palanteer feature 'stacktrace' enabled for viewer
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBUNWIND)
      does not match the name of the calling package (LibUnwind).  This can lead
      to problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibUnwind.cmake:23 (find_package_handle_standard_args)
      c++/testprogram/CMakeLists.txt:24 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    CMake Warning (dev) at /opt/cmake/3.19.8/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
      The package name passed to `find_package_handle_standard_args` (LIBDW) does
      not match the name of the calling package (LibDw).  This can lead to
      problems in calling code that expects `find_package` result variables
      (e.g., `_FOUND`) to follow a certain pattern.
    Call Stack (most recent call first):
      cmake/FindLibDw.cmake:23 (find_package_handle_standard_args)
      c++/testprogram/CMakeLists.txt:25 (find_package)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    Palanteer feature 'stacktrace' enabled for testprogram
    -- Found Python3: /usr/bin/python3.8 (found version "3.8.5") found components: Interpreter 
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /home/bareya/git/palanteer/build
    [email protected] ~/g/p/build (main)> make 
    Scanning dependencies of target palanteer
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwConfig.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwConst.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwFileDialog.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwFontData.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMain.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainCommon.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainHistogram.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainMarker.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainMemory.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainPlot.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainProfile.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainRecordCatalog.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainSearch.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainText.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwMainTimeline.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwPlatform.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/vwReplayAlloc.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmCnx.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmCompress.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmLiveControl.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmRecord.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmRecordIterator.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/common/cmRecording.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsGlHelper.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsOsLinux.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsOsWindows.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/base/bsString.cpp.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/debug.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/entropy_common.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/error_private.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/fse_decompress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/pool.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/threading.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/xxhash.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/common/zstd_common.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/fse_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/hist.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/huf_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress_literals.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress_sequences.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_compress_superblock.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_double_fast.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_fast.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_lazy.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_ldm.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstd_opt.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/compress/zstdmt_compress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/huf_decompress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/zstd_ddict.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/zstd_decompress.c.o
    [100%] Building C object server/viewer/CMakeFiles/palanteer.dir/__/external/zstd/decompress/zstd_decompress_block.c.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui_draw.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui_tables.cpp.o
    [100%] Building CXX object server/viewer/CMakeFiles/palanteer.dir/__/external/imgui/imgui_widgets.cpp.o
    [100%] Linking CXX executable ../../bin/palanteer
    [100%] Built target palanteer
    Scanning dependencies of target testprogram
    [100%] Building CXX object c++/testprogram/CMakeFiles/testprogram.dir/testProgram.cpp.o
    [100%] Building CXX object c++/testprogram/CMakeFiles/testprogram.dir/testPart.cpp.o
    [100%] Linking CXX executable ../../bin/testprogram
    [100%] Built target testprogram
    Scanning dependencies of target python_instrumentation
    [100%] Generating python_instrumentation_install
    running install
    running bdist_egg
    running egg_info
    writing /home/bareya/git/palanteer/python/palanteer.egg-info/PKG-INFO
    writing dependency_links to /home/bareya/git/palanteer/python/palanteer.egg-info/dependency_links.txt
    writing top-level names to /home/bareya/git/palanteer/python/palanteer.egg-info/top_level.txt
    reading manifest file '/home/bareya/git/palanteer/python/palanteer.egg-info/SOURCES.txt'
    writing manifest file '/home/bareya/git/palanteer/python/palanteer.egg-info/SOURCES.txt'
    installing library code to build/bdist.linux-x86_64/egg
    running install_lib
    running build_py
    running build_ext
    creating build/bdist.linux-x86_64/egg
    error: could not create 'build/bdist.linux-x86_64/egg': Permission denied
    make[2]: *** [python/CMakeFiles/python_instrumentation.dir/build.make:84: python/python_instrumentation_install] Error 1
    make[1]: *** [CMakeFiles/Makefile2:230: python/CMakeFiles/python_instrumentation.dir/all] Error 2
    make: *** [Makefile:103: all] Error 2
    
    bug scripting 
    opened by bareya 2
  • pip install palanteer fails

    pip install palanteer fails

    Hello, I am trying to install palanteer package but im hitting the below issue. Any pointers would be greatly appreciated.

    Installing collected packages: palanteer
      Running setup.py install for palanteer ... error
      error: subprocess-exited-with-error
      
      × Running setup.py install for palanteer did not run successfully.
      │ exit code: 1
      ╰─> [35 lines of output]
          running install
          /proj/xsjsswstaff/tejuss/miniconda3/lib/python3.7/site-packages/setuptools/command/install.py:37: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
            setuptools.SetuptoolsDeprecationWarning,
          running build
          running build_py
          creating build
          creating build/lib.linux-x86_64-3.7
          creating build/lib.linux-x86_64-3.7/palanteer
          copying palanteer/__main__.py -> build/lib.linux-x86_64-3.7/palanteer
          copying palanteer/__init__.py -> build/lib.linux-x86_64-3.7/palanteer
          running build_ext
          building 'palanteer._cextension' extension
          creating build/temp.linux-x86_64-3.7
          creating build/temp.linux-x86_64-3.7/palanteer
          creating build/temp.linux-x86_64-3.7/palanteer/_cextension
          /proj/xsjsswstaff/tejuss/miniconda3/bin/x86_64-conda_cos6-linux-gnu-cc -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -O2 -Wall -Wstrict-prototypes -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /proj/xsjsswstaff/tejuss/miniconda3/include -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /proj/xsjsswstaff/tejuss/miniconda3/include -fPIC -I/proj/xsjsswstaff/tejuss/miniconda3/include/python3.7m -c palanteer/_cextension/pyPalanteerInstrumentation.cpp -o build/temp.linux-x86_64-3.7/palanteer/_cextension/pyPalanteerInstrumentation.o -I palanteer/_cextension
          cc1plus: warning: command line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++
          In file included from palanteer/_cextension/pyPalanteerInstrumentation.cpp:46:0:
          palanteer/_cextension/palanteer.h: In member function 'void plPriv::CliManager::registerCli(plCliHandler_t, const char*, const char*, const char*, plPriv::hashStr_t, plPriv::hashStr_t, plPriv::hashStr_t)':
          palanteer/_cextension/palanteer.h:2440:55: error: expected ')' before 'PRId64'
                                   int readQty = sscanf(s, "[[%" PRId64 "]]", &p.defaultValue);
                                                                 ^~~~~~
          palanteer/_cextension/palanteer.h:2440:83: warning: spurious trailing '%' in format [-Wformat=]
                                   int readQty = sscanf(s, "[[%" PRId64 "]]", &p.defaultValue);
                                                                                             ^
          palanteer/_cextension/palanteer.h:2440:83: warning: too many arguments for format [-Wformat-extra-args]
          palanteer/_cextension/palanteer.h: In member function 'const char* plPriv::CliManager::execute(const char*, plPriv::plRemoteStatus&)':
          palanteer/_cextension/palanteer.h:2537:42: error: expected ')' before 'PRId64'
                                   if(sscanf(s, "%" PRId64, &_cio._paramValues[paramIdx])!=1 || !skipValue(s))
                                                    ^~~~~~
          palanteer/_cextension/palanteer.h:2537:78: warning: spurious trailing '%' in format [-Wformat=]
                                   if(sscanf(s, "%" PRId64, &_cio._paramValues[paramIdx])!=1 || !skipValue(s))
                                                                                        ^
          palanteer/_cextension/palanteer.h:2537:78: warning: too many arguments for format [-Wformat-extra-args]
          error: command '/proj/xsjsswstaff/tejuss/miniconda3/bin/x86_64-conda_cos6-linux-gnu-cc' failed with exit code 1
          [end of output]
      
      note: This error originates from a subprocess, and is likely not a problem with pip.
    error: legacy-install-failure
    
    × Encountered error while trying to install package.
    ╰─> palanteer
    
    note: This is an issue with the package mentioned above, not pip.
    hint: See above for output from the failure. 
    
    
    opened by tejus26 3
  • Request: Search -> New Plot with option to create plot for the selected function across *all* threads/fibers

    Request: Search -> New Plot with option to create plot for the selected function across *all* threads/fibers

    In the following image, I'm looking to see all cases of "PredictFlights" across the recorded timespan, but they're instead plotted per thread (in this case per fiber), which as you can see, is quite a lot! It would take a long time to manually add each fiber's call(s) to a single plot. I had a look at the code but it's all new to me so figured I'd throw a request in here too :)

    image

    opened by BrodyHiggerson 1
  • make errors

    make errors

    Getting the following errors when trying to build on: Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-1160.71.1.el7.x86_64 Architecture: x86-64 cmake version: 3.24.2 make: GNU Make 3.82 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

    The error I'm seeing is: /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bsOsLinux.cpp:840:93: error: no matching function for call to ‘bsDate::bsDate(<brace-e nclosed initializer list>)’ return bsDate{1900+t->tm_year, 1+t->tm_mon, t->tm_mday, t->tm_hour, t->tm_min, t->tm_sec}; ^ /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bsOsLinux.cpp:840:93: note: candidates are: In file included from /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bsOsLinux.cpp:41:0: /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bs.h:101:8: note: constexpr bsDate::bsDate() struct bsDate { ^ /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bs.h:101:8: note: candidate expects 0 arguments, 6 provided /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bs.h:101:8: note: constexpr bsDate::bsDate(const bsDate&) /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bs.h:101:8: note: candidate expects 1 argument, 6 provided /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bs.h:101:8: note: constexpr bsDate::bsDate(bsDate&&) /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bs.h:101:8: note: candidate expects 1 argument, 6 provided /home/jupyterhub3/baburn/curr_sandboxes/open_src_tools/palanteer/server/base/bsOsLinux.cpp: In function ‘bsDate osGetCreationDate(const bsString&)’:

    question 
    opened by bsburns 2
  • Question - Shared libraries

    Question - Shared libraries

    Has the library a design for working in separated projects but they can be connected with one static library? I mean is it possible to create one class with implementation where it is a wrapper for palanteer. Otherwise, I can't understand why the header file doesn't include code even if I declare preprocessor PL_IMPLEMENTATION clearly in .cpp file.

    Or the purpose of this library is to test small codebases because I can't imagine how to use it if you have many separated projects that are connected with one main static library.

    As the result, I have the error LNK2019: unresolved external symbol. Describe the correct usage of your header in the case when I want to use the implementation in .cpp file, but have declarations of functions (USE_PL) in a header file and share it between all projects. It's really sad if I can't do that at all.

    opened by wh1t3lord 11
  • Hard to interpret fiber work when looking at list of threads

    Hard to interpret fiber work when looking at list of threads

    Since you previously mentioned workflow and usability wrt fibers, I figured I'd make this post, although I appreciate it's likely a bit more ambitious.

    There are a few issues I see in this area.

    The way I use FTL is to have every bit of work be performed by fibers - to the point that my 'main' thread of execution is just another fiber pinned to a specific worker. I have lot of fibers and use them for everything.

    When I look at this view, it doesn't really tell me what's going on, and I can't gleam much from it wrt what work is executing when/where. Highlighting a fiber span does highlight the corresponding function stack in the latter parts of the window, but this is difficult to see. image

    In FTL, the default number of fibers is 400, which, as you can imagine, blows up the size of the "Fibers" area quite a bit (and possibly hits an error message wrt thread limits from memory - can't check right now), and makes the aforementioned highlighting not really useful - which of the 400 fibers is being highlighted? No idea!

    Ideally, there would be a thread-first view of the worker threads that shows the work being performed on them as normal; i.e. how you would see work displayed on threads without using fibers - I think it matters less which fiber # is active when, and instead more which callstack is active when on which thread. So in this example on the left wouldn't be fibers but instead the worker threads executing any and all fibers, showing the work those threads are performing, with Palanteer doing the magic of tying fiber-based work to the threads that execute it.

    image

    Hopefully that makes sense. Again, totally appreciate it's a bunch of work. Just wanted to provide my perspective; happy to test any ideas in this area, incremental changes, prototypes, etc.

    viewer 
    opened by BrodyHiggerson 2
  • [Proof of Concept] MacOS Platform Layer

    [Proof of Concept] MacOS Platform Layer

    This is a rough pass at a MacOS platform layer for the Palanteer viewer application (note that I have not touched the instrumentation or scripting layer yet, and I haven't tested the networked recording, just loading trace files).

    @dfeneyrou Huge props for making a really great profiling tool and writing it in such a way that porting to a new platform is feasible in a tractable amount of time. Please let me know if having a MacOS platform layer in the codebase is something you'd be interested in. I don't mind either way; this is mostly a learning project for me.

    This is not really in a mergeable state yet, but I wanted to open it up for feedback and discussion on the approach. I've never written a shippable platform layer before and don't have a lot of experience with native MacOS APIs.

    From a usability perspective, the two biggest outstanding problems are

    • [ ] https://github.com/dfeneyrou/palanteer/issues/19
    • [ ] https://github.com/dfeneyrou/palanteer/issues/18

    Also:

    • [ ] the MacOS menus are not interactive while the main window has focus. I have no idea why yet.
    • [ ] the cmake changes are not well considered. I don't really know how to use cmake and would love suggestions on how to structure them better.
    • [ ] this still uses OpenGL, which is deprecated on MacOS. A Metal rendering backend would be faster and more likely to stay usable into the future, but I wouldn't know where to start since the existing platform layer is OpenGL only and doesn't have any hooks for other APIs like Vulkan or DirectX.
    opened by jceipek 0
Releases(v0.6)
  • v0.6(Dec 30, 2021)

    This is a feature delivery release

    Compared to the previous release, the main added changes are:

    • Feature (global): efficient printf-like logging (supersedes markers).
      • nanosecond logging performance
      • format arguments can be searched and graphed
    • Feature in the viewer: some exports have been added
    • Important fix: instrumentation crash under stress
    • Important fix: correctness of multi-resolution graphs

    Behavior change / compatibility break

    • Viewer: the marker window has been replaced with the log window, which generalizes markers and provides more features
    • Viewer: old stored records will not be readable anymore (incompatibility due to somes changes for the logs)
    • Instrumentation: old viewers are not compatible, due to transport header change.
    • Instrumentation: plMarker APIs are deprecated.
      • they are currently wrapped on plLogWarn function and will be removed soon

    New features

    • Global: efficient printf-like logging
      • nanosecond logging performance
      • format arguments can be searched and graphed
      • a comparison with Nanolog and spdlog is provided
    • Viewer: some exports available
      • anywhere with ctrl-P for screen capture
      • in main menu bar for Chrome Trace Format (JSON)
      • in text and log windows for a text export
      • in plot windows for CSV export

    Fixes and improvements

    • C++ instru: remove a critical flaw in the event collection mechanism which could lead to a crash under stress (thanks @gpascualg for the report with details)
    • Python instru: the filename of the exception source is now provided in the log text, along with the line number
    • Viewer: reworked the computation of the multi-resolution of the graphs. Previous version was broken and provided poor visual results
    • Viewer: fix the profiling applied always on a particular thread, for threads without provided names (thanks @jojado8408 for reporting)
    • Code cleaning: fix "issues" highlighted by the tool include-what-you-use
    • Code cleaning: fix "issues" highlighted by the static analysis tool CodeChecker
    • Code cleaning: remove warnings when compiling under Windows with the flag /W4 /permissive- (thanks @gpascualg and @BrodyHiggerson)
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.6.0.Python.instrumentation.wheels.zip(321.70 KB)
    Palanteer.v0.6.0.scripting.wheels.zip(1.54 MB)
    Palanteer.v0.6.0.Windows.binaries.zip(1.01 MB)
  • v0.5(Nov 21, 2021)

    This is a feature delivery release

    Compared to the previous release, the main added features are:

    • Multi-stream (or multi-process) recording
    • Automatic C++ instrumentation (GCC only)

    Behavior change / compatibility break

    • Viewer: external string lookups are now per record (they were previously per application).
    • Viewer: old stored records will not be readable anymore (incompatibility due to the added stream informations)
    • Instrumentation: old viewers are not compatible, due to transport header change.

    New features

    • Server and Viewer: add support for multistream (or multiprocess) records
      • Server: support for multiple socket connections and multistream recording
      • Viewer: add the configuration menu for the mono/multi stream
      • Viewer: file dialog supports multi selection with highlight
      • Viewer: record options are displayed per stream
    • Viewer: enable Dear ImGui keyboard navigation
    • Instrumentation: support of automatic C++ function instrumentation (GCC only) The external string lookup is now independent for each record, and covers also this feature.
    • Python: add support for Python 3.10 packages

    Fixes and improvements

    • Viewer: lock use can now be graphed for all threads (menu on the lock name)
    • Viewer: in Text view, all events with dates are now taken into account for navigation
    • Viewer: fix a crash when asking an histogram for a "lock use" scope
    • Viewer: fix persistence of graphs between launches
    • Viewer: fix a crash when the saved layout is not matching the record thread names
    • Viewer: fix the display of the used size of records (now 64 bits size)
    • Server: more robust handling of duplicated thread names
    • Server: fix a crash when getting memory details with big quantity of non released allocations
    • Python: fix an incorrect event logging sequence when both using coroutines and tracing C calls
    • Python instru: disable an annoying warning on Windows
    • C++ instru: collect the used language, the context switch collection state and the auto instrumentation state
    • C++ instru: waiting for server connection is now a configurable timeout, no more a binary state
    • C++ instru & server: more robust short date handling
    • C++ instru: more robust initialization
    • C++ instru: threads (standard or virtual) can be declared before service initialization and are persistent across multiple service initialization (thanks @BrodyHiggerson for the use case)
    • C++ instru: reduced disabled Palanteer include cost on windows with USE_PL=0 (now a few millisecond, as for Linux)
    • Scripting: improve support of external strings, now applied also on the event specification
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.5.0.Python.instrumentation.wheels.zip(321.20 KB)
    Palanteer.v0.5.0.scripting.wheels.zip(1.93 MB)
    Palanteer.v0.5.0.Windows.binaries.zip(997.06 KB)
  • v0.4(Sep 9, 2021)

    This is a bug fix release

    Behavior change / compatibility break

    • None

    New features

    • Viewer: add support for high DPI

    Fixes and improvements

    • Python instrumentation: fix a crash when tracing C calls
    • Viewer: fix a crash in some cases in the file dialog window when playing with sorting
    • C++ instrumentation: added printf-like API for plDeclareVirtualThread and plDeclareThreadDyn
    • Documentation updated
    • Documentation: upgraded Markdeep
    • Viewer: upgraded Dear ImGui
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.4.0.Python.instrumentation.wheels.zip(267.65 KB)
    Palanteer.v0.4.0.scripting.wheels.zip(1.55 MB)
    Palanteer.v0.4.0.Windows.binaries.zip(980.55 KB)
  • v0.3(Aug 16, 2021)

    This is a general maintenance release

    Compared to the previous release, the main changes are:

    • Addition of the 'compact application model' taking advantage of 32 bits architectures to reduce the exchanged data to 12 bytes per event (instead of 24 bytes)
    • 10% speed gain on server side (compression library update)

    Behavior change / compatibility break

    • Viewer: old stored records will not be readable anymore (break in 6a1bcdf13e79f1ffa666682e502b444bcf739f20)
    • Instrumentation: old viewers are not compatible, due to added options (see below). But the current viewer accept older instrumentation libraries.

    New features

    • Instrumentation: add support for a hash 'salt', useful when using 32 bits hash to remove potential collisions.
    • Instrumentation: add support for the 'compact model', allowing 50% reduction of used bandwidth (i.e. 12 bytes per event) between client and server, under some instrumentation constraints
    • Python: add interface to profile Python modules (thanks @Victor333Huesca!)
    • Scripting improved API to handle the case of externally launched programs (thanks @LotemAm!)
    • Viewer: application icon added under Windows

    Fixes and improvements

    • Viewer: display of all instrumentation options in the 'Record view'
    • Instrumentation: Added the missing "group" version of plDeclareThread
    • Server: add the missing control of the instrumentation protocol version, to detect client-server incompatibilities
    • Documentation updated
    • Viewer: application icon added under Windows
    • Server: upgraded compression library zstd to benefit from the recent speed improvement for low compression ratios.
    • Viewer: upgraded Dear ImGui and stb_image.h
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.3.0.Python.instrumentation.wheels.zip(266.39 KB)
    Palanteer.v0.3.0.scripting.wheels.zip(1.55 MB)
    Palanteer.v0.3.0.Windows.binaries.zip(979.04 KB)
  • v0.2(Jul 31, 2021)

    This is the first Palanteer official release

    Compared to the initial commit, the main changes are:

    • Virtual/userland thread support
    • Stability fixes (one of them critical)
    • Improved packaging.

    Behavior change / compatibility break

    • Viewer: old stored records will not be readable anymore (break in 8e9e9ac721692222f516fcff0346925f1597f30c)
    • The Python instrumentation does not log anymore the C calls by default. Indeed, wildly used built-in function (like list "append") may be very heavy and are not always necessary

    New features

    • Viewer: record catalog improvement: total size per app is displayed and a menu to collapse/open alls app was added
    • Server: 10% faster event processing on server side by disabling specific assertions in containers in release mode.
    • Virtual/green/userland thread support in C++, and the equivalent asyncio/gevent/greenlet in Python
    • Improved CMakeFile.txt (thanks @bareya, @RichieSams!)
    • Python packages are now wheels
    • Python code is now formatted for PEP8 (with the tool "black")

    Fixes

    • Server: fixed the lock event automata (a not taken lock event after a wait begin event was not ended as it should)
    • Viewer: fixed the search on Windows (strcasestr exists but does not work properly)
    • Viewer: fixed the behavior of clicking on items in the text view
    • Viewer: fixed the plot and histogram layout persistency
    • Server: filter problematic characters for a file in the sent application name
    • Server: improve robustness and behavior of the server connection automata
    • Server: improve robustness of the server against corrupted data sent from instrumentation
    • Instrumentation; fixed a major stability issue (event corruption) in the collection mechanism
    • Viewer: fixed proper quitting of the viewer
    • Instrumentation: fixed missing deactivated APIs (thanks @Lnsrini, @learn-more)
    • Tools: fixed missing API names in the tool extStringCppParser.py
    • Documentation improvement (thanks @ajweeks!)
    Source code(tar.gz)
    Source code(zip)
    Palanteer.v0.2.0.Python.instrumentation.wheels.zip(264.85 KB)
    Palanteer.v0.2.0.scripting.wheels.zip(1.47 MB)
    Palanteer.v0.2.0.Windows.binaries.zip(944.92 KB)
Owner
Damien Feneyrou
Damien Feneyrou
A Python library for inspecting JVM class files (.class)

lawu Lawu is a human-friendly library for assembling, disassembling, and exploring JVM class files. It's highly suitable for automation tasks. Documen

Tyler Kennedy 45 Oct 23, 2022
For Tok-k passages that have passed through the Bi-Encoder Retrival, ReRank is performed using CrossEncoder.

Cross-Encoder-with-Bi-Encoder For Tok-k passages that have passed through the Bi-Encoder Retrival, ReRank is performed using CrossEncoder. Data Data u

7 Feb 09, 2022
Mines all the moneys and stuff and things.

NFT Miner NFT Miner - Version 1.1.0 - Quick Fix Since the whole NFT thing started booming on Twitter it's been hard not to see one of those ugly ass m

8w8 1 Dec 13, 2021
京东热爱狂欢趴&京东扫码获取cookie

京东热爱狂欢趴 一键完成任务脚本来袭 活动地址: https://wbbny.m.jd.com/babelDiy/Zeus/2s7hhSTbhMgxpGoa9JDnbDzJTaBB/index.html#/home 2021-06-02更新: 1、删除京东星推官 2、更新脚本,修复火爆问题 2021

xoyi 48 Dec 28, 2022
A practice program to find the LCM i.e Lowest Common Multiplication of two numbers using python without library.

Finding-LCM-using-python-from-scratch Here, I write a practice program to find the LCM i.e Lowest Common Multiplication of two numbers using python wi

Sachin Vinayak Dabhade 4 Sep 24, 2021
Goddard A collection of small, simple strategies for Freqtrade

Goddard A collection of small, simple strategies for Freqtrade. Simply add the strategy you choose in your strategies folder and run. ⚠️ General Crypt

Shane Jones 118 Dec 14, 2022
Open Source Management System for Botanic Garden Collections.

BotGard 3.0 Open Source Management System for Botanic Garden Collections built and maintained by netzkolchose.de in cooperation with the Botanical Gar

netzkolchose.de 1 Dec 15, 2021
Driving lessons made simpler. Custom scheduling API built with Python.

NOTE This is a mirror of a GitLab repository. Dryvo Dryvo is a unique solution for the driving lessons industry. Our aim is to save the teacher’s time

Adam Goldschmidt 595 Dec 05, 2022
Dotfiles & list of programs

dotfiles & list of programs So I wanted to just backup my most used files. I have a bad habit, sometimes I get tired of a distro and do a wipe and sta

2 Sep 04, 2022
uMap lets you create maps with OpenStreetMap layers in a minute and embed them in your site.

uMap project About uMap lets you create maps with OpenStreetMap layers in a minute and embed them in your site. Because we think that the more OSM wil

771 Dec 29, 2022
The Official interpreter for the Pix programming language.

The official interpreter for the Pix programming language. Pix Pix is a programming language dedicated to readable syntax and usability Q) Is Pix the

Pix 6 Sep 25, 2022
A proof-of-concept package manager for Cairo contracts/libraries

glyph A proof-of-concept package manager for Cairo contracts/libraries. Distribution through pypi. Installation through existing package managers -- p

Sam Barnes 11 Jun 06, 2022
A python script to make leaderboards using a CSV with the runners name, IDs and Flag Emojis

SrcLbMaker A python script to make speedrun.com global leaderboards. Installation You need python 3.6 or higher. First, go to the folder where you wan

2 Jul 25, 2022
A free micro-blog written in Python and powered by Heroku. *Merge requests are appreciated!*

Background Hobo is an ultra-lightweight blog engine written in Python. It has two dependencies, fully integrated into the codebase with no additional

Andrew Nelder 48 Jan 28, 2021
Code repo for the book "Feature Engineering for Machine Learning," by Alice Zheng and Amanda Casari, O'Reilly 2018

feature-engineering-book This repo accompanies "Feature Engineering for Machine Learning," by Alice Zheng and Amanda Casari. O'Reilly, 2018. The repo

Alice Zheng 1.3k Dec 30, 2022
CoreSE - basic of social Engineering tool

Core Social Engineering basic of social Engineering tool. just for fun :) About First of all, I must say that I wrote such a project because of my int

Hamed Mohammadvand 7 Jun 10, 2022
ThnoolBox - A thneed is a multi-use versatile object

ThnoolBox Have you ever wanted a collection of bodged desktop apps that are Lorax themed ? No ? Sucks to suck I guess Apps & their downsides CalculaTh

pocoyo 1 Jan 21, 2022
The next generation Canto RSS daemon

Canto Daemon This is the RSS backend for Canto clients. Canto-curses is the default client at: http://github.com/themoken/canto-curses Requirements De

Jack Miller 155 Dec 28, 2022
A powerful and user-friendly binary analysis platform!

angr angr is a platform-agnostic binary analysis framework. It is brought to you by the Computer Security Lab at UC Santa Barbara, SEFCOM at Arizona S

6.3k Jan 02, 2023
Painel simples com consulta de cep,CNPJ,placa e ip

Painel mpm Um painel simples com consultas de IP, CNPJ, CEP e PLACA Início 🌐 apt update && apt upgrade -y pkg i python git pip install requests Insta

8 Feb 27, 2022