Testing this some more, and based on suggestion from Cameron, I have made a
copy of the default Seasons template, and enabled in weewx.conf.
Going through and removing pieces I don't have (ET, UV, etc) from
skin.conf, [DisplayOptions], got my generation from 2m27s to 2m20s (no
appreciable change)
I'm not sure. The reason mine are missing is that *I have chosen* them to
be missing. I don't want them automatically re-created.
With the V4 skin it was happy checking for the existence of each parameter
and then ignoring any that weren't there.
In my case, I have customised DBs and a heavi
On Thursday, December 28, 2023 at 5:26:09 AM UTC-8 Tom Keffer wrote:
Alternatively, one could write a specialized algorithm for windchill. The
sensible thing to do would be to read a year's worth of temperature and
wind speed, all in one go --- one database access. Then use the results to
calcu
Swapping out default Seasons with the old version resulted in no change. I do
notice skin.conf still says 4.10.2. The previous Seasons skin I believe I had
modified because the station info defaults to saying “Vantage Pro2” (since
that’s the station type in weewx.conf), but I have a Vantage Vue,
Well, I would not place too much value on my interpretation of the profile,
but here is the sorted list of calls that totalled over 1 second. The total
within sqlite.py is less than 20 seconds. It spent longer than that just
converting to and fro between C and F
Ordered by: internal time
That comparison was basically what I was investigating - on-the-fly calcs
taking minutes, vs fractions of a seconds to retrieve from a DB.
Add to that... to do the calculation you might need to retrieve twice as
much data anyway and redo the day-archive calculations every cycle.
As you suggest,
>
> I wonder if this could be organized into
>
> a database accessor to get multiple columns, that results in a stream
> of N values
>
> functions that accept N values to compute something else
> (e.g. windchill from temp/wind).
>
> a function that takes a computing function and a stream
"'Cameron D' via weewx-development"
writes:
> My assumption would be that any derivable value that you want to plot
> should be a column in the database. Even if you could speed it up, the
> calculation it would need to be by a factor approaching 100 to be a useful
> choice.
> I think that us
My assumption would be that any derivable value that you want to plot
should be a column in the database. Even if you could speed it up, the
calculation it would need to be by a factor approaching 100 to be a useful
choice.
I think that using derived parameters for only a "current" display shou
Tom Keffer writes:
> Very useful data, Cameron.
>
> Right now, if you want one year's worth of say, windchill, and it's not in
> the database, it is calculated one record at a time. For a 5 minute archive
> interval, that's 100k+ database accesses. It's a general algorithm, but
> it's slow.
>
> A
Very useful data, Cameron.
Right now, if you want one year's worth of say, windchill, and it's not in
the database, it is calculated one record at a time. For a 5 minute archive
interval, that's 100k+ database accesses. It's a general algorithm, but
it's slow.
Alternatively, one could write a spe
OK, this "ability to generate synthetic types" was the clue to the
excessive cpu and time.
I started with a copy of my main DB converted to sqlite and trimmed it to 5
minute intervals and ~100k archive records, so it is close to the benchmark
db.
I did a bit of (my first ever) python profiling
12 matches
Mail list logo
