-
-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Super slowly Time.parse #195
Comments
I ran into an issue that I suspected might be related to this, where I was parsing a lot of times and adjusting them using Active Support's I'm running Ruby 3.1.2 on an M1 Pro.
With
With
|
Example repo https://github.com/bragovo/falcon-time-example with results. |
Can you try with and without the TZ environment variable set? |
Did you notice that when hosting it in Puma, it fails with:
which is much faster than |
Puma running with a single thread
Results
Puma with 16 threads
Results
Falcon with single thread
Results
Falcon with 16 processes
Results
|
The conclusions I can draw from the data:
The real solution here is to figure out why cc @nateberkopec just FYI as it's an interesting result. Puma with 16 workers and 1 thread each
Results
|
Checked puma and falcon in single mode and with TZ:
|
2023-02-22-nqvGoqWxIv.speedscope.json.zip This is speedscope log for https://www.speedscope.app/ |
@bragovo did you add |
There is no any problem with time and puma for me... hmmm..
I added debug output https://github.com/bragovo/falcon-time-example/commit/e71d2335f5ba9ae2e48e2137a965b45a099204d9
The same behavior. |
I could reproduce it on macOS but not Linux, I wonder why. |
It looks like, in this case,
Falcon
Puma
|
|
It seems called much less on Puma:
|
Yeap, true. Usually I run app on docker alpine image and didn't see the differences, but once I run onto host machine )) Actually on linux Time with Falcon slower than Puma, not so dramatically but exists. About 15-20% slower. I have an endpoint with 10k records (dont ask me why :-D) from PG (with Sequel), and |
The issue can be reproduced just with |
Here is a repro without Falcon: require 'benchmark'
require 'async'
require 'time'
require 'stackprof'
def sir_local_alot
result = Benchmark.measure do
10_000.times do
tm = ::Time.local(2023)
end
end
$stderr.puts result
end
sir_local_alot
require 'async/container'
Console.logger.debug!
container = Async::Container.new
container.spawn do |task|
sir_local_alot
end
Console.logger.debug "Waiting for container..."
container.wait
Console.logger.debug "Finished." |
Here is a repro without falcon or async: require 'benchmark'
require 'time'
def sir_local_alot
result = Benchmark.measure do
10_000.times do
tm = ::Time.local(2023)
end
end
$stderr.puts result
end
sir_local_alot
pid = fork do
sir_local_alot
end
Process.wait(pid) |
It looks like |
As this is not a bug with Falcon but some kind of issue on macOS / |
@ioquatix That's my measurements on Linux (Debian):
I run you example:
Sure, it's not 300x, but ~2x. |
When you measure the C API, it's 300x slower. |
Hmm, ok 👌 |
We couldn't reproduce the extreme deviation on Linux, and we also found some hacks to fix it on macOS, e.g. |
There is simple app:
Response time:
450 ms - falcon
15 ms - puma
15 ms - rackup
If change to
DateTime.parse("2022-10-24 12:33:44.054237")
:13.3 ms - falcon
11.5 ms - puma
11 ms - rackup
How I can fix it?
falcon (0.42.3)
async-http (0.59.3)
async (2.2.1)
rack (2.2.4)
ruby 3.1.2p20
The text was updated successfully, but these errors were encountered: