Re: [xmltv-users] tv_grab_na_sd (new grabber for your consideration)

On Sat, Jul 9, 2016 at 6:15 PM, Kevin Groeneveld <[email protected]> wrote:

> I just committed a change to my grabber which can double the performance in
> some cases.  After running a profiler I found that the DateTime parsing and
> comparisons were (and still are to some extent) adding a lot to the
> execution time.

Yeah, I found the same thing at one point, and did
some reorganization to avoid some of the repeated
conversions, but not all can be eliminated and still
do the right thing.  There are many good reasons
DateTime parsing can be slow (I am not a hard
core time geek, but I dabble(*)), but perl is especially
slow in some cases.  I presume if someone really
cared they would rewrite some of the function in C
(just like the json parsing code has both the pure
perl and the C compiled variant for performance).

> I am not sure how the performance now compares to Gary's grabber.  I really
> should actually try running his sometime...

TBH, while improving the performance is always
a good thing, I did not spend much time trying
to eke out the last bits of performance, since it
(typically) is only going to be run a few times a
day, and run in background at that.  I remember
running my grabber on a slow ARM system
(with limited memory, and limited disk speed
and limited CPU power), and while it took quite
some time to complete the run, I did not really
care all that much (it was primarily more of a
test as to whether it would run at all).  For the
most common use case (likely to be a DVR),
the host system is likely to be something a
bit more robust than my toy armv7 system.

btw, at one point, I seem to recall that another
slow section was (somewhere) buried in the xml
writer.  I did not spend any time looking at that
either ("not my problem", combined with the
alternative was bypassing all the careful work
others have done to insure xml output is correct
and valid, which is not where I wanted to invest
my time right then).

And then there is my personal use case, which
is mythtv, and when running mfdb, mythtv
itself (and mysql, etc.) used more total resources
than the grabber as part of the mfdb guide
loading, so I sort of backed away from trying
to address small improvements, since it was
not going to substantially improve the total
elapsed time.  So, yes, I got lazy.

Gary


(*) btw, leap second at the end of the year!
Prepare now to spend your extra second in
style.  Here is one way to spend your leap
second:  http://spendyourleapsecondhere.com/

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape