Peformance digression when using "proc" notation for arrows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Peformance digression when using "proc" notation for arrows

Artem
I have also asked this question on stackoverflow where the full code snippet is listed. (https://stackoverflow.com/questions/45260173/proc-syntax-in-haskell-arrows-leads-to-severe-performance-penalty)
 
I am facing a weird digression when using the following code:
 
sumArr = scan (\acc x -> let !newAcc = acc + x in newAcc) 0
sumArr' = proc v -> do sumArr -< v

testData :: [Int]
testData = [1..1000000]

main = print $ L.last $ evalList sumArr' testData
Running time for main with sumArr (i.e. no proc notation) is 0.087 sec, while for sumArr' it is 3.2 seconds (and around 300mb memory usage), although sumArr' is just sumArr called within a proc block.
 
Can some body explain what is causing this difference? Is there some laziness induced by the use of proc? And how and when proc gets desugared?
 
Thank you.
 
 
Artem
 
-------- Конец пересылаемого сообщения --------

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Peformance digression when using "proc" notation for arrows

Brandon Allbery
On Sun, Jul 23, 2017 at 6:26 PM, Artem <[hidden email]> wrote:

sumArr
= scan (\acc x -> let !newAcc = acc + x in newAcc) 0 sumArr' = proc v -> do sumArr -< v testData :: [Int] testData = [1..1000000] main = print $ L.last $ evalList sumArr' testData
Running time for main with sumArr (i.e. no proc notation) is 0.087 sec, while for sumArr' it is 3.2 seconds (and around 300mb memory usage), although sumArr' is just sumArr called within a proc block.

Absent other information (like the core from each) I would be tempted to think that the problem is some stream fusion RULES either did not fire or degraded into a pessimization.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Loading...