6 ms·

I don't think this was an 'oh my god we're trying to track down why cabal update is so slow and we just can't find it' issue like you make it out to be. edit:

I don't think this was an 'oh my god we're trying to track down why cabal update is so slow and we just can't find it' issue like you make it out to be. edit: http://www.reddit.com/r/haskell/comments/1sh67u/the_reason_why_cabal_update_takes_so_long/cdxnr5l http://www.reddit.com/r/haskell/comments/1sh67u/the_reason_w... This comment by the patch author indicates that actually tracking it down was a fairly straightforward profiling job.

zvrba 13y ago
I didn't try to imply that it was difficult to find the performance problem. It's an observation on something else: Haskell is often mentioned for its equational reasoning. I find it interesting that correct equational reasoning in this case lead to a correct program, but one with absymal performance. It'd be interesting to think how one could encode performance characteristics into equations.
- jjaredsimpson 13y ago
  Its known that postpending to a linked list is slow. It's just a property of the data type.
- deleted 13y ago
  [deleted]
- Peaker 13y ago
  I think having simple and direct denotational semantics necessarily means having relatively complex, indirect operational semantics (e.g: Haskell). Having a simple and direct operational semantics necessarily means having complex and indirect denotational semantics (e.g: C). C makes performance easy and correctness hard. Haskell makes correctness easy and performance hard. The trick is, in most programs, you only need performance for a tiny subset of the program. You need correctness throughout the whole program.
  - zvrba 13y ago
    Why do you think that there must be a tradeoff between simplicity of denotational and operational semantics?
    - Peaker 13y ago
      Because operational semantics (of contemporary computers, at least) are very different from a simple denotational semantics. We have to bridge that gap: 1) Either use a compiler that hides away the operational details 2) Or use a language that directly maps to the operational semantics, but then is necessarily far away from the denotational ones
- velis_vel 13y ago
  > I find it interesting that correct equational reasoning in this case lead to a correct program, but one with absymal performance. That's not really an interesting property of Haskell, though. You can always write correct but slow code in any language. > It'd be interesting to think how one could encode performance characteristics into equations. I've seen the concept of encoding performance in types played around with, but I can't find actual work (if any) that's been done on it.
  - eru 13y ago
    > You can always write correct but slow code in any language. Yes, but Haskell makes that exceptionally easy.

zvrba 13y ago

I didn't try to imply that it was difficult to find the performance problem. It's an observation on something else: Haskell is often mentioned for its equational reasoning. I find it interesting that correct equational reasoning in this case lead to a correct program, but one with absymal performance. It'd be interesting to think how one could encode performance characteristics into equations.

jjaredsimpson 13y ago
Its known that postpending to a linked list is slow. It's just a property of the data type.
deleted 13y ago
[deleted]
Peaker 13y ago
I think having simple and direct denotational semantics necessarily means having relatively complex, indirect operational semantics (e.g: Haskell). Having a simple and direct operational semantics necessarily means having complex and indirect denotational semantics (e.g: C). C makes performance easy and correctness hard. Haskell makes correctness easy and performance hard. The trick is, in most programs, you only need performance for a tiny subset of the program. You need correctness throughout the whole program.
- zvrba 13y ago
  Why do you think that there must be a tradeoff between simplicity of denotational and operational semantics?
  - Peaker 13y ago
    Because operational semantics (of contemporary computers, at least) are very different from a simple denotational semantics. We have to bridge that gap: 1) Either use a compiler that hides away the operational details 2) Or use a language that directly maps to the operational semantics, but then is necessarily far away from the denotational ones
velis_vel 13y ago
> I find it interesting that correct equational reasoning in this case lead to a correct program, but one with absymal performance. That's not really an interesting property of Haskell, though. You can always write correct but slow code in any language. > It'd be interesting to think how one could encode performance characteristics into equations. I've seen the concept of encoding performance in types played around with, but I can't find actual work (if any) that's been done on it.
- eru 13y ago
  > You can always write correct but slow code in any language. Yes, but Haskell makes that exceptionally easy.