ChaseGilliam

ChaseGilliam

Phoenix did really well on the data updates (2nd best) but not as well on multiple queries, which should be roughly analagous. I wonder what’s up with that.

1
Post #72
sztosz

sztosz

In Multiple Queries it’s just SELECT + serialization to json. In Data Updates it’s SELECT + UPDATE + serialization to json. You have relevant code here: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Elixir/phoenix/web/controllers/page_controller.ex But i don’t judge those reults, neither looked at any optimizations.

But… i don’t like this try → resque, and why String.to_integer/1, and not Integer.parse/1 also why params["queries"] and not Map.fetch(params, :queries) It all looks too much like ruby or python… i don’t know. And as much I love Python, and work in Ruby(don’t love it though ;P) You have much better ways to express intent in Elixir, so why not use it?

I just don’t trust those benchmarks at all :wink:

1
Post #73
Nicd

Nicd

They’re not equivalent though. It would be Map.fetch(params, "queries"). Personally I would pattern match it in the function head (def queries(conn, %{"queries" => queries_param}) do).

1
Post #74
sztosz

sztosz

True, i forgot about GC not collecting symbols :slight_smile:

2
Post #75
ChaseGilliam

ChaseGilliam

Pattern matching is probably faster too, Have you considered putting in a PR?

2
Post #77
dsissitka

dsissitka

I believe today is the last day they’ll accept pull requests for round 13.

I’m testing it now. If it is I’ll try to get one in in time.

3
Post #78
PragTob

PragTob

thanks for working on it and submitting PRs to fix the benchmarks!

1
Post #79
Nicd

Nicd

I have too much work right now, it’s not possible. If @dsissitka can make one, that’s great!

1
Post #80
dsissitka

dsissitka

I was curious to see if replacing what they have now…

q = try do
  case String.to_integer(params["queries"]) do
    x when x < 1    -> 1
    x when x > 500  -> 500
    x               -> x
  end
rescue
  ArgumentError -> 1
end

…with something like…

q = case Integer.parse(params["queries"]) do
  {x, _} when x < 1   -> 1
  {x, _} when x > 500 -> 500
  {x, _}              -> x
  :error              -> 1
end

…would have a significant effect on performance.

In short, their code (~677 RPS) was about 2% slower than my code (~691 RPS) and my code was about 0.6% slower than hard-coding q (~695 RPS). With differences that small I’m not sure how much of it was the code and how much of it was the testing environment.

Unfortunately we missed the deadline for round 13 pull requests. :frowning:

https://github.com/TechEmpower/FrameworkBenchmarks/pull/2348#issuecomment-260073040

2
Post #81