On Mon, 29 Mar 2021, Allin Cottrell wrote:
On Mon, 29 Mar 2021, klaus.hasenbach(a)web.de wrote:
> Thank you, Allin!
>
> But I guess there is a bug in dbnonmics 0.4 with Windows 10. Bundle
> requests via mask are slow as before (see for examble the attached scipt).
I see what you mean. Running a slightly cut-down version of your multi-series
request, with mask "DEU+GBR+IAA..Q" and a maximum of 250 series, I'm seeing
timings and JSON sizes as follows:
dbnomics 0.4, with metadata: 0m56.569s, 2317360 bytes
dbnomics 0.4, no metadata: 0m55.649s, 2296071 bytes
So cutting out the metadata makes little difference to the time or
size. (Up till now we haven't been setting metadata=0 for this
sort of request -- we missed this case -- but it hardly helps.)
If I invoke the dbnomics v21 API instead, I get this:
time 0m4.886s, size 1905768 bytes
I still have to determine what's taking 10 times as long: dbnomics
or gretl's processing of the data. But at this point my suspicion
is that it's dbnomics.
I was wrong. The retrieval time is very similar across the v21 and
v22 APIs. What was taking so long was something that I believe is
now quite unnecessary, namely "fixing" the dataset "dimensions"
objects in the retrieved JSON. I think we were doing this because
(a) it seemed to us that the v22 API was kinda broken at one point
and/or (b) that gretl didn't support nested arrays and so some
complex translation was needed. (We now have nested arrays.)
Anyway, I'll put out version 0.41 of the dbnomics addon shortly,
with the "fix dimensions" code de-activated. It would be good if
people can check for any breakage that may result!
Allin