brendanib
Joined 14 years ago
Karma
273
Submissions
71
Member since
Mar 8
Recent submissions
Comment · 4 months ago
Comment · 2 years ago
There's no hard limit on duration! 30 seconds of CPU time
https://developers.cloudflare.com/workers/platform/limits/#d...
Comment · 2 years ago
Would love feedback on which packages you'd like to see us support:
https://github.com/cloudflare/workerd/discussions/categories...
Comment · 2 years ago
Three aspects of performance:
1. Cold start perf 2. Post-cold start perf - The cost of bridging between JS and WebAssembly - The speed of the Python interpreter running in WebAssembly
Today, Python cold starts are slower than cold starts for a JavaScript Worker of equivalent size. A basic "Hello World" Worker written in JavaScript has a near zero cold start time, while a Python Worker has a cold start under 1 second.
That's because we still need to load Pyodide into your Worker on-demand when a request comes in. The blog post describes what we're working on to reduce this — making Pyodide already available upfront.
Once a Python Worker has gone through a cold start though, the differences are more on the margins — maybe a handful milliseconds, depending on what happens during the request.
- There is a slight cost (think — microseconds not milliseconds) to crossing the "bridge" between JavaScript and WebAssembly — for example, by performing I/O or async operations. This difference tends to be minimal — generally something measured in microseconds not milliseconds. People with performance sensitive Workers already write them in Rust https://github.com/cloudflare/workers-rs, which also relies on bridging between JavaScript and WebAssembly.
- The Python interpreter that Pyodide provides, that runs in WebAssembly, isn't as fast as the years and years of optimization that have gone into making JavaScript fast in V8. But it's still relatively early days for Pyodide, compared to the JS engine in V8 — there are parts of its code where we think there are big perf gains to be had. We're looking forward to upstreaming performance improvements, and there are WebAssembly proposals that help here too.
Comment · 11 years ago
I've been using this for a few months now and it's amazing. They're moving crazy fast to support ES6 features, and the interface for writing a new rule is great.
Comment · 11 years ago
I've been using this for almost three months now and it's fantastic, hard to work without it.
Comment · 12 years ago
We are collecting anonymous data about the network, browser, etc. and tying it back to core metrics like call length, but there's always more we can do. I'm really hoping that more browsers start to support the network information API natively too: https://developer.mozilla.org/en-US/docs/WebAPI/Network_Info...
Comment · 12 years ago
Thanks Roger -- we really want to create a connection quality indicator like you describe, kind of like the number of bars on your cell connection.
One of our biggest frustrations with existing services is that it's hard to tell why the call quality is poor - is it my connection, your connection, or the service's fault?
Can I shoot you an email when we get a beta version of that indicator working? I'd love to get your feedback on it.
Comment · 12 years ago
Let's say you send a link to someone on an iOS device -- we can prompt them to install a native app, then as soon as they open the app, with no login, your call starts.
Apple actually is refusing to add WebRTC to Safari, because if you have good HTML5 support and WebRTC, you can do much more outside of a native app, which hurts their ability to control the app ecosystem, and helps developers ship to Android and iOS on the same day. I hope this changes, but right now it doesn't seem promising.
Comment · 12 years ago
Right now they're very similar, but we're working on getting Awesometalk onto more platforms than just the web. We want you to be able to send anyone an Awesometalk link, and no matter what device they're using, have a conversation.
Comment · 12 years ago
Thanks for the feedback, sorry your first call didn't go well.
When the connection is poor, as it sounds like it was in this case, would you be okay if we fell back to audio-only and explained why? This seems like a better experience than trying to fight through lag, but we want to be careful not to arbitrarily cut off your video feed.
it already uses Workers Cache for the route-level ISR cache