- 121
- 4
The problem is that the program uses too much CPU. As explained here, after buildingI've built with:
the function tokenAndSignature takes 26.7% of CPU time with 43.2% allocs. Also it happens so that it's the function which result is used later by lens to decode JSON from. Inner functions of tokenAndSignature contain many decodeLenientWithTable functions (from Data.ByteString.Base64.Internal module) with 550000 entries on average which looks awkward to me.
Yes, I use String type here. But it's only because wreq's library get function requires String as its argument.
The problem is that the program uses too much CPU. As explained here, after building with:
the function tokenAndSignature takes 26.7% of CPU time with 43.2% allocs. Also it happens so that it's the function which result is used later by lens to decode JSON from.
Yes, I use String type here. But it's because wreq's library get function requires String as its argument.
The problem is that the program uses too much CPU. As explained here, I've built with:
tokenAndSignature takes 26.7% of CPU time with 43.2% allocs. Also it happens so that it's the function which result is used later by lens to decode JSON from. Inner functions of tokenAndSignature contain many decodeLenientWithTable functions (from Data.ByteString.Base64.Internal module) with 550000 entries on average which looks awkward to me.
Yes, I use String type here. But it's only because wreq's library get function requires String as its argument.
- 121
- 4
Making Low performance of HTTP request using Haskell wreq
In addition to huge binary size (38MB stripped) theThe problem is that it takesthe program uses too much CPU cycles. As explained here, after building with:
the function tokenAndSignature takes 26.7% of CPU time with 43.2% allocs. And I really see high CPU usage in "htop" system monitor when program runs. ItAlso it happens so that it's the function which result is used later by lens to decode JSON from.
I use default configurationstack exec -- test +RTS -sstderr shows that almost 1/3 of stack with "ghc-optionstime is spent on GC: -threaded -rtsopts -with-rtsopts=-N".
MUT time 1.604s ( 5.535s elapsed)
GC time 0.514s ( 0.505s elapsed)
...
Productivity 76.9% of total user, 28.2% of total elapsed
Making HTTP request using Haskell wreq
In addition to huge binary size (38MB stripped) the problem is that it takes too much CPU cycles. As explained here, after building with:
the function tokenAndSignature takes 26.7% of CPU time with 43.2% allocs. And I really see high CPU usage in "htop" system monitor when program runs. It happens so that it's the function which result is used later by lens to decode JSON from.
I use default configuration of stack with "ghc-options: -threaded -rtsopts -with-rtsopts=-N".
Low performance of HTTP request using Haskell wreq
The problem is that the program uses too much CPU. As explained here, after building with:
the function tokenAndSignature takes 26.7% of CPU time with 43.2% allocs. Also it happens so that it's the function which result is used later by lens to decode JSON from.
stack exec -- test +RTS -sstderr shows that almost 1/3 of time is spent on GC:
MUT time 1.604s ( 5.535s elapsed)
GC time 0.514s ( 0.505s elapsed)
...
Productivity 76.9% of total user, 28.2% of total elapsed