While working on improvements for the package list endpoint, I noticed a few things.
First, even with a local flagrow.io instance, it takes about 1.7 seconds to load the list of packages when not cached. But once cached, performance can greatly increase:
Before my improvements, I noticed we were caching the raw text response from flagrow.io, but were parsing it and extracting the data key each time. By moving the code around I checked the following. (Time is the average in seconds for 5000 readings from the cache, I did the serie a few times for each case). The cache was already filled at the start of the test.
Cache body, then decode and get: 0.00787021498680110.0077699553966522
Cache body and decode, then get: 0.0061107920169830.00560952339172360.0055253109931946
Cache body, decode and get: 0.00563481459617610.0060723432064056
Caching the raw text clearly has no advantage. The serialized version of the output of json_decode is parsed quicker than JSON itself.
I'm closing this issue immediately, I just wanted a trace of this to stay somewhere. But it's irrelevant in the code because it's closely tied to my own machine.
While working on improvements for the package list endpoint, I noticed a few things.
First, even with a local flagrow.io instance, it takes about 1.7 seconds to load the list of packages when not cached. But once cached, performance can greatly increase:
Before my improvements, I noticed we were caching the raw text response from flagrow.io, but were parsing it and extracting the data key each time. By moving the code around I checked the following. (Time is the average in seconds for 5000 readings from the cache, I did the serie a few times for each case). The cache was already filled at the start of the test.
0.00787021498680110.00776995539665220.0061107920169830.00560952339172360.00552531099319460.00563481459617610.0060723432064056Caching the raw text clearly has no advantage. The serialized version of the output of
json_decodeis parsed quicker than JSON itself.I'm closing this issue immediately, I just wanted a trace of this to stay somewhere. But it's irrelevant in the code because it's closely tied to my own machine.