›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

srp_stopwatch

AusMarkBAusMarkB
in SRP Utilities
Everybody should use this.

Wish I had implemented it sooner.

That is all.

Comments

  • DonBakkeDonBakke
    I couldn't agree more. SRP Stopwatch is one of the most underrated goodies in the SRP Utilities portfolio. It has become one of my most valued tools for debugging, troubleshooting, and optimizing code. It is simple to use, lightweight, and works across multiple stored procedures. We probably should just write a full "how to" or "best practice" blog article on how to use it. We mentioned it and provided some sample code in this blog post from last January, but I don't think it gives SRP Stopwatch the attention it deserves.
  • AusMarkBAusMarkB
    I admit, it was one of those things I read about somewhere and thought, might try that some day....

    Suddenly being slammed with performance complaints in http api's and ten minutes or so of implementing srp_stopwatch() throughout and I have real numbers and pointers to places other than where I would've thought the problem lies.

    Simple. Invaluable. Underrated until you've got a real problem to solve.

    By the way, anyone know of a way to make attach_table() more efficient?
  • DonBakkeDonBakke
    No magic bullet for Attach_Table I'm afraid. Are you attaching tables that are dynamically generated or are they pre-generated? If the latter, could you store their handles away in a record and retrieve them via Xlate?
  • AusMarkBAusMarkB
    Food for thought, thanks Don. Wasn't really expecting a magic bullet. It was just kind of a reference to the fact that I assumed my selects were the problem but generally speaking 50 - 95% of each request time is spent attaching tables.

    Of course I can still work on tweaking the problem selects but if I can get improvements in the attach then that's improvement in every single request.
    I was using our generic attach routine which attaches everything. There's my first problem. I shall be more selective about what I attach as I only need a fraction of the tables for http stuff. That should be a step in the right direction, then if I need more I'll see about implementing your suggestion.
  • MattCrozierMattCrozier
    Hmm, I seem to be getting a VNAV crash on the ShowAll service, line 253. This is with SRP Utilities versions 1.5.7 and 1.5.8. My test is very simple:
    call srp_stopwatch('Reset') call srp_stopwatch('Start','t') call delay( 4) call srp_stopwatch('Stop','t') call srp_stopwatch('ShowAll')
    Is this just me? It works for the Show service (curiously, showing less than 4 seconds !?)
  • DonBakkeDonBakke
    M@ - I think you found a bug, but it is limited to stopwatches of a certain name. If you change "t" to "test", does it work?
  • BarryStevensBarryStevens
    if i change t to tt it works
  • DonBakkeDonBakke
    Yep...it's a bug with stopwatch names with only one character in length. We'll fix this. In meantime, use a meaningful stopwatch name for goodness sakes! :)
  • MattCrozierMattCrozier
    Ha - who'd've thought! ;).

    Can I be really lazy and ask that I'm just timing one block of code, that the stopwatch name be optional (perhaps defaulted internally) ? ;)
  • DonBakkeDonBakke
    No, you may not ask.
  • MattCrozierMattCrozier
    ;)
  • DonBakkeDonBakke
    edited November 2016
    If you would all be so kind to test the updated SRP_Stopwatch utility I would appreciate that very much. The following should be addressed:
    • Fix bug so stopwatch names of only a single character will be supported.
    • Added support for a default stopwatch. So, using the Start and Stop services can be used without the Name argument.

    SRPStopwatch.zip
  • MattCrozierMattCrozier
    Nice! I've tried both of these plus various other scenarios and all is good. This streamlines quick one-off benchmarks just a tad ;)

    Thanks Don!
Sign In or Register to comment.