Enabling Skyfield Almanac Very Slow Report Generation

175 views
Skip to first unread message

Rory Gillies

unread,
Jan 10, 2026, 12:00:05 PMJan 10
to weewx-user
I would love to use Karen K's Skymap almanac extension, however when I enable Skyfield in weewx.conf my report generation goes from 10 seconds to 125 seconds or more! In fact sometimes it takes so long that it has not completed when the next reporting instance starts. Any ideas? I know skyfield is slower than pyephem but 12 times slower seems a bit excessive.

I am using a modified version of NeoWX Material, I don't use the Seasons skin but it executes normally if I enable it, so it must be something in NeoWX. Also, I enabled the forecast skin and that took over 100 seconds to execute, normally takes less than a second.

If anyone has any pointers where to look that would be appreciated.

Tom Keffer

unread,
Jan 10, 2026, 3:58:12 PMJan 10
to weewx...@googlegroups.com
You're on the right track. The only way to diagnose slow report generation is to delete parts of the skins bit-by-bit, and see what makes a difference.

The log can also be helpful. Look at the timestamps and see where the time is going.

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/a53e2518-b5b7-486f-b9f5-2b975dc30b1en%40googlegroups.com.

Karen K

unread,
Jan 11, 2026, 7:27:13 AMJan 11
to weewx-user
Most likely the reason is, what is described in section genVisibleTimespans() of the documentation. There, a special generator function is described that returns timespans of visibility. It reads:

"If you wonder why you could not use a loop over the days as the tags $week.days, $month.days, and $year.days provide and then calculate rising and setting time, here is the answer: You can do so with PyEphem, but unfortunately this approach is 125 times slower with Skyfield. Therefore a specialized method is required."

Karen K

unread,
Jan 11, 2026, 9:22:08 AMJan 11
to weewx-user
Another thought: In case you use weewx-GTS you need the last version of it together with the Skyfield almanac, otherwise this extension can slow down report generation a lot.

Karen K

unread,
Jan 11, 2026, 10:15:42 AMJan 11
to weewx-user
Example how to use genVisibleTimespans() to get a table of Moon risings and Moon settings:

#from weewx.units import ValueTuple, ValueHelper

<!DOCTYPE html>

<html lang="$lang">

  <head>

    <meta charset="UTF-8" />

    <title>genVisibleTimespans() example</title>

    <meta name="description" content="an example how to use this function" />

    <style>

      td, th { padding-left:5px; padding-right:5px; }

    </style>

  </head>

  <body>

    <h1>$gettext("Moon rise and set of the current month")</h1>

    <table>

      <tr>

        <th>$gettext('Rise')</th>

        <th>$gettext('Set')</th>

      </tr>

      #for $timespan in $almanac.moon.genVisibleTimespans(context='month')

      #set $rise_vh = $ValueHelper(ValueTuple($timespan[0],'unix_epoch','group_time'),context='month',formatter=$station.formatter)

      #set $set_vh = $ValueHelper(ValueTuple($timespan[1],'unix_epoch','group_time'),context='month',formatter=$station.formatter)

      <tr>

        <td>$rise_vh</td>

        <td>$set_vh</td>

      </tr>

      #end for

    </table>

  </body>

</html>




Rory Gillies

unread,
Jan 11, 2026, 5:54:03 PMJan 11
to weewx...@googlegroups.com
Cheers Karen. I do use WeeWX GTS and I also have some rise / set times for all the major planets, sun and moon. I’ll get GTS updated and have a look through the skyfield documentation for the rise / set working.

Rory

On 11 Jan 2026, at 14:22, Karen K <kk44...@gmail.com> wrote:

Another thought: In case you use weewx-GTS you need the last version of it together with the Skyfield almanac, otherwise this extension can slow down report generation a lot.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/xOZIS--A6Jk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/df7560c1-3445-4980-929f-ec43e44b668cn%40googlegroups.com.

Karen K

unread,
Jan 12, 2026, 3:53:50 PMJan 12
to weewx-user
I added some documentation. And I made it possible that almanac_time can take a list of timestamps to speed up things. #19

John Kline

unread,
Aug 1, 2026, 8:47:29 PM (12 hours ago) Aug 1
to weewx...@googlegroups.com, weewx-user
Hi Rory,

I’m reviving this thread because it discusses the forecast extension, which I maintain.
  
The report that the forecast skin took over 100 seconds caught my attention, since it renders in about 2 seconds on my hardware.  I was able to reproduce the slowdown, and I can now say where it comes from.
  
I rendered the stock forecast skin -- all 12 sample pages, live NWS forecast data -- on a Raspberry Pi 5 under three different almanacs.  Identical skin, identical data; times are from the cheetahgenerator log line:
      
    built-in PyEphem almanac:     3.6 seconds    
    weewx-skyfield:                       4.4 seconds  (2.4 s steady-state in weewxd)
    weewx-skyfield-almanac:      81 seconds
  
So the slowdown reported here is real, and weewx-GTS is not needed to explain it -- my test system has no GTS installed.  On a machine slower than a Pi 5, 81 seconds lands right in the range you reported.
  
The mechanism: the forecast skin builds a fresh $almanac for every forecast period and asks each one for sunrise, sunset, moonrise, and moonset.  The strip pages do this for up to 300 periods, on several pages, which adds up to a few thousand rise/set searches per report cycle.  A single Skyfield rise/set search costs roughly 15-20 ms on a Pi 5, so an almanac that runs every search on every tag access lands at 80+ seconds.  PyEphem's searches are simply much cheaper, which is why this access pattern was never a problem before.
  
Many tags asking the same few astronomical questions is normal for WeeWX skins, so my weewx-skyfield extension [1] caches event searches inside its engine.  Forecast period timestamps repeat within a page, across pages, and across report cycles, so nearly every search after the first is a cache hit.  That is the entire difference: 4.4 seconds versus 81 seconds for the same skin doing the same work, both with a JPL ephemeris and current Skyfield.
  
The practical takeaway: Skyfield accuracy does not have to cost you your report time, and no skin changes are needed -- the stock forecast skin is fine as written.
  
I did not test the modified NeoWX Material skin from the original post, but any skin that loops over almanac rise/set tags is subject to the same arithmetic.
  

Cheers,
John

On Jan 12, 2026, at 12:53 PM, Karen K <kk44...@gmail.com> wrote:

I added some documentation. And I made it possible that almanac_time can take a list of timestamps to speed up things. #19

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/e961cc4a-bf9e-4a2b-8d68-ba35a9a4036en%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages