Newest at the top
| 2025-01-11 19:40:53 +0100 | rekahsoft | (~rekahsoft@70.51.99.237) rekahsoft |
| 2025-01-11 19:40:49 +0100 | pera | (~pera@user/pera) (Ping timeout: 248 seconds) |
| 2025-01-11 19:40:33 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-11 19:39:08 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-01-11 19:38:30 +0100 | <bailsman> | Back when I was profiling this, using Generic, derive-storable and storable vectors was like 100x faster than either normal Haskell lists (pure) or boxed mutable vectors. Although that was kind of a micro benchmark and my code has grown somewhat. Haven't checked if it still holds now. I also didn't study the core output in detail. |
| 2025-01-11 19:38:11 +0100 | <geekosaur> | (SYB predates GHC generics and is still going strong) |
| 2025-01-11 19:37:33 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-01-11 19:37:10 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
| 2025-01-11 19:36:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 19:36:17 +0100 | <probie> | If you want to know about the performance penalty (if any), you might be able to answer the question by making GHC to spit out the core and seeing what it looks like |
| 2025-01-11 19:36:10 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-01-11 19:35:53 +0100 | <geekosaur> | on the one hand, enough people don't care that GHC.Generics is still widely used; on the other, enough people do care that SYB, Uniplate, generics-sop, and another that I'm not finding quickly and never remember the name of are also widely used |
| 2025-01-11 19:35:18 +0100 | <bailsman> | In theory you could annotate them right? With the actual original type? Although it would require you to add a special optimization pass for generics. |
| 2025-01-11 19:34:37 +0100 | <geekosaur> | my understanding, as I said earlier, is that generation and consumption of Generic representations are too separated to be optimized |
| 2025-01-11 19:33:47 +0100 | <bailsman> | but getField and setField I would have expected to be zero cost |
| 2025-01-11 19:33:41 +0100 | <bailsman> | I can kind of see why toJSON wouldn't work. Because it's probably too clever to optimize out |
| 2025-01-11 19:33:18 +0100 | <geekosaur> | (the same Gneric rep is used for anything that consumes a Generic instance for whatever reason; that "whatever reason" is typically per typeclass) |
| 2025-01-11 19:33:10 +0100 | _73 | (~user@pool-173-76-100-193.bstnma.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2025-01-11 19:32:36 +0100 | <geekosaur> | it's not, no. generation of the Generic representation of a type is entirely separate from consumption and may be spread over both space and time |
| 2025-01-11 19:32:34 +0100 | <bailsman> | And the same happens to getField and setField? Those go and figure out the actual field to use at runtime based on the generic representation of my type? And this doesn't get inlined and optimized away? |
| 2025-01-11 19:31:29 +0100 | <geekosaur> | the compiler does not generate the serialize-to-JSON code, a default typeclass method for the ToJSON typeclass implements that at runtime |
| 2025-01-11 19:31:16 +0100 | <bailsman> | but why isn't this "as if" i manually defined those derived instances? Isn't the compiler perfectly capable of optimizing the original out? |
| 2025-01-11 19:30:29 +0100 | <geekosaur> | compile time creates the data structures representing the structure of a value, runtime traverses them to actually do things with those values (such as serialize to JSON) |
| 2025-01-11 19:29:35 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-01-11 19:29:16 +0100 | <bailsman> | I thought it all happened at compile time BTW |
| 2025-01-11 19:29:10 +0100 | <bailsman> | It describes how to use it, not how expensive it is to use at runtime |
| 2025-01-11 19:28:40 +0100 | <geekosaur> | GHC.Generics is documented in its haddock |
| 2025-01-11 19:28:17 +0100 | <geekosaur> | although I guess if you want automated deriving of instances it's TH, GHC.Gnenerics, or compiler plugins (not that I know any implementations that use the latter) |
| 2025-01-11 19:27:43 +0100 | <bailsman> | Anyway what's the actual runtime cost of GHC.Generics? How does it work? Is this documented anywhere? I was overjoyed that it all just worked automatically as soon as I imported generic-lens and started putting deriving Generic on all my records. |
| 2025-01-11 19:27:27 +0100 | <geekosaur> | sop offers TH support but I think doesn't depend on it |
| 2025-01-11 19:26:05 +0100 | <haskellbridge> | <magic_rb> I cant even comprehend i compiled within 20 miliseconds :) let alone figure out what to do next |
| 2025-01-11 19:25:53 +0100 | <haskellbridge> | <maerwald> bailsman: Well, one can dream |
| 2025-01-11 19:25:34 +0100 | <bailsman> | You're probably using template haskell :P |
| 2025-01-11 19:25:20 +0100 | <geekosaur> | yeh, but my context is expecting 5 minutes to compile, what's 20 seconds? |
| 2025-01-11 19:25:01 +0100 | <bailsman> | Programmeer feedback loops should be measured in milliseconds, not seconds. 20 seconds to compile is completely unacceptable. |
| 2025-01-11 19:24:54 +0100 | <geekosaur> | uniplate, syb, generics-sop |
| 2025-01-11 19:24:27 +0100 | <haskellbridge> | <magic_rb> geekosaur its not just you, im 20 and i dont think 20 seconds to compile is that bad. Gives me time to take a break, relax, plan my next move |
| 2025-01-11 19:24:05 +0100 | <bailsman> | so basically whenever I update a field I'm going through generics |
| 2025-01-11 19:23:59 +0100 | <bailsman> | Right now I'm having generics generate "setField" and "getField" for me so I can use overloadedrecordupdate |
| 2025-01-11 19:23:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-11 19:23:33 +0100 | <bailsman> | actually* |
| 2025-01-11 19:23:29 +0100 | <bailsman> | Why isn't it a zero cost abstraction? What acceptable happens if I use generics everywhere? |
| 2025-01-11 19:22:39 +0100 | <geekosaur> | they did, you just don't get them from ghc |
| 2025-01-11 19:22:25 +0100 | <bailsman> | Someone should make generics fast btw, they're very useful |
| 2025-01-11 19:22:19 +0100 | <bailsman> | yes waiting 10 seconds for it to compile is unacceptable, waiting an extra nanosecond at runtime is fine |
| 2025-01-11 19:22:05 +0100 | <geekosaur> | but I'm from the 80s, you kids think a few extra seconds is slow 🙂 |
| 2025-01-11 19:21:50 +0100 | <geekosaur> | mm. my take on that is that I usually compile a few times and run many times, so runtime performance matters to me more |
| 2025-01-11 19:21:14 +0100 | <bailsman> | Generating lenses with template haskell just completely destroys my compilation speeds |
| 2025-01-11 19:21:05 +0100 | <bailsman> | I'm using generics for everything already. To make my records storable, and whenever I access record fields, for example. I didn't know it was slow at runtime. Oops. (I hadn't noticed yet, so I guess its good enough) |
| 2025-01-11 19:19:35 +0100 | <geekosaur> | one for your removal of IO, the other for the ToJSON instance which is probably via Generics unless you're writing it by hand |