gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

✘profiling -- looking for the usual suspects


From: Gary E. Miller
Subject: ✘profiling -- looking for the usual suspects
Date: Sun, 17 Apr 2022 15:35:09 -0700

Yo All!

Since I do not want to toucht the code until most everyone is happy
with rc1, I spent time with gprof, the GNU profiler.

The results for a u-blox binary stream:

$ gpsdecode < test/daemon/ublox-zed-f9p_hpg1.11.log

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ms/call  ms/call  name    
 63.93      0.39     0.39   124065     0.00     0.00  packet_parse
 11.48      0.46     0.07 33653178     0.00     0.00  nextstate
  9.84      0.52     0.06    70740     0.00     0.00  nmea_parse
  6.56      0.56     0.04    17658     0.00     0.00  ubx_msg_rxm_rawx
  3.28      0.58     0.02   124065     0.00     0.00  gpsd_error_model
  1.64      0.59     0.01   584197     0.00     0.00  strlcpy
  1.64      0.60     0.01   106206     0.00     0.00  
earth_distance_and_bearings
  1.64      0.61     0.01                             processGRS

Everything else is less than 1%

Anyone wanting to speed things up should look at:
        packet_parse()
        nextstate()
        nmea_parse()

The nitty-gritty packet parsing stuff.  Before any floating point.

Here are the results for an NMEA stream:

This is "gpsdecode < test/daemon/telit-he910.log"

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls   s/call   s/call  name    
 28.57      0.38     0.38   400406     0.00     0.00  nmea_parse
 18.80      0.63     0.25   402976     0.00     0.00  packet_parse
 12.78      0.80     0.17 21081967     0.00     0.00  nextstate
  5.26      0.87     0.07   865062     0.00     0.00  safe_atof
  4.51      0.93     0.06   259567     0.00     0.00  json_tpv_dump
  3.01      0.97     0.04  7605597     0.00     0.00  str_appendf
  3.01      1.01     0.04   402977     0.00     0.00  gpsd_poll
  3.01      1.05     0.04   400406     0.00     0.00  generic_parse_input
  2.26      1.08     0.03                             _init
  2.26      1.11     0.03   402976     0.00     0.00  gpsd_error_model
  2.26      1.14     0.03    66821     0.00     0.00  gpsd_zero_satellites
  2.26      1.17     0.03    48316     0.00     0.00  fill_dop
  1.50      1.19     0.02   600095     0.00     0.00  nmeaid_to_prn
  1.50      1.21     0.02   112566     0.00     0.00  processGSV

Everything else is less than 1%

The top three are our old friends:
        nmea_parse()
        packet_parse()
        nextstate()

Most of nmea_parse() is a linear search for a sentence match.  Almost
time to do something smarter there, like a binary search.

Number 4, at 5.26% is a small-ish function: safe_atof()

If someone wants to optimize some floating point, there is the place to
look.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpGEO1l1Ihav.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]