[Ur] TechEmpower Benchmarks
escalier at riseup.net
escalier at riseup.net
Mon Nov 4 14:19:50 EST 2013
Thanks. I made the suggested changes and submitted a pull request the
benchmarkers.
> having multiple integer types seems pretty retro
Yeah, I mostly agree. I just thought I'd ask since it is a benchmark.
> On 11/02/2013 05:55 PM, escalier at riseup.net wrote:
>> I drafted a submission for the TechEmpower Web framework benchmarks
>> (results here: http://www.techempower.com/benchmarks/ | specs here:
>> http://www.techempower.com/benchmarks/#section=code&hw=i7&test=json).
>>
>
> Oh, neato! Around 2008 I started looking for existing benchmarks that
> would make for good comparisons with Ur/Web, and there were depressingly
> few out there. It's good to learn about this one; and I'm very
> interested in helping get the Ur/Web tests into the official
> comparison. (Though what I'd _really_ like would be a benchmark that
> measures programmer productivity somehow on less trivial tasks.)
>
>> Would anyone with more Ur/Web expertise be willing to look over my
>> submission?
>> (https://github.com/pseudonom/FrameworkBenchmarks/blob/master/UrWeb/bench.ur)
>>
>
> I winced reading the code to add "Date" and "Server" headers, but I see
> that these are a required feature. ;)
>
> You can use the infix operator [%] instead of calling the [mod] function.
>
> The first pattern below is redundant, I think, if you change the third
> pattern to just [_]:
>> val on = case qt of
>> None => Some 1
>> | Some ("queries", x) => read x
>> | Some _ => Some 1
> ...and I'm cross with the benchmark authors for the requirement to
> handle nasty query strings missing this parameter or giving it in the
> wrong format!
>
> Maybe define a function to encapsulate all the boilerplate for returning
> a JSON chunk? It could even include a call to [addHeaders].
>
> What do you think about adding loud comments to this file, clearly
> delineating the different test types?
>
>> Areas that I know need attention:
>> - I defined my own `map2` rather than using `Top.map2` to avoid figuring
>> out the typing for `Top.map2`
>>
>
> [Top.map2] is for records, not lists, so it wouldn't have done what you
> want anyway. I've added your function (generalized in the usual
> polymorphic way) to the standard library as [ListPair.map2].
>
> After I added the function and looked more closely at where you're using
> it, I wonder why you don't just replace this code:
> rands' <- List.mapM (fn _ => rand) rq;
> let
> val rows' = map2 (fn x y => x -- #RandomNumber ++ {RandomNumber =
> clamp y}) rows rands'
> with this code:
> rows' <- List.mapM (fn r => n <- rand; return (r -- #RandomNumber
> ++ {RandomNumber = clamp n})) rows
>
>> - To get a list of random Ints of length x, I `List.mapM (fn _ =>
>> rand)`
>> over a range from 1 to x
>>
>
> I believe you could do this more nicely, using standard library code
> that I _didn't_ just add (;]), with:
> List.tabulateM (fn _ => rand) x
>
>> - Ur/Web seems to expect an 'int8' where an 'int' would suffice
>> - Ur/Web seems to expect a 'text' where a 'varchar' would suffice
>>
>
> Sure, but is this really a problem? I view it more as avoiding
> unnecessary fanciness! (E.g., having multiple integer types seems
> pretty retro to me, for most contexts.)
>
> On 11/02/2013 05:55 PM, escalier at riseup.net wrote:
>> I drafted a submission for the TechEmpower Web framework benchmarks
>> (results here: http://www.techempower.com/benchmarks/ | specs here:
>> http://www.techempower.com/benchmarks/#section=code&hw=i7&test=json).
>>
>
> Oh, neato! Around 2008 I started looking for existing benchmarks that
> would make for good comparisons with Ur/Web, and there were depressingly
> few out there. It's good to learn about this one; and I'm very
> interested in helping get the Ur/Web tests into the official
> comparison. (Though what I'd _really_ like would be a benchmark that
> measures programmer productivity somehow on less trivial tasks.)
>
>> Would anyone with more Ur/Web expertise be willing to look over my
>> submission?
>> (https://github.com/pseudonom/FrameworkBenchmarks/blob/master/UrWeb/bench.ur)
>>
>
> I winced reading the code to add "Date" and "Server" headers, but I see
> that these are a required feature. ;)
>
> You can use the infix operator [%] instead of calling the [mod] function.
>
> The first pattern below is redundant, I think, if you change the third
> pattern to just [_]:
>> val on = case qt of
>> None => Some 1
>> | Some ("queries", x) => read x
>> | Some _ => Some 1
> ...and I'm cross with the benchmark authors for the requirement to
> handle nasty query strings missing this parameter or giving it in the
> wrong format!
>
> Maybe define a function to encapsulate all the boilerplate for returning
> a JSON chunk? It could even include a call to [addHeaders].
>
> What do you think about adding loud comments to this file, clearly
> delineating the different test types?
>
>> Areas that I know need attention:
>> - I defined my own `map2` rather than using `Top.map2` to avoid figuring
>> out the typing for `Top.map2`
>>
>
> [Top.map2] is for records, not lists, so it wouldn't have done what you
> want anyway. I've added your function (generalized in the usual
> polymorphic way) to the standard library as [ListPair.map2].
>
> After I added the function and looked more closely at where you're using
> it, I wonder why you don't just replace this code:
> rands' <- List.mapM (fn _ => rand) rq;
> let
> val rows' = map2 (fn x y => x -- #RandomNumber ++ {RandomNumber =
> clamp y}) rows rands'
> with this code:
> rows' <- List.mapM (fn r => n <- rand; return (r -- #RandomNumber
> ++ {RandomNumber = clamp n})) rows
>
>> - To get a list of random Ints of length x, I `List.mapM (fn _ =>
>> rand)`
>> over a range from 1 to x
>>
>
> I believe you could do this more nicely, using standard library code
> that I _didn't_ just add (;]), with:
> List.tabulateM (fn _ => rand) x
>
>> - Ur/Web seems to expect an 'int8' where an 'int' would suffice
>> - Ur/Web seems to expect a 'text' where a 'varchar' would suffice
>>
>
> Sure, but is this really a problem? I view it more as avoiding
> unnecessary fanciness! (E.g., having multiple integer types seems
> pretty retro to me, for most contexts.)
>
More information about the Ur
mailing list