Both RDBMS have good performance. Lots of the issues we ran into really are related to scale. If you know that your data set will never be particularly large, most of these issues will not come up. Other issues like managing replicas, promotions, etc. will be shared between RDBMS.
One of the nice things about PostgreSQL regardless of scale are the tools they provide for optimizing your application. EXPLAIN and EXPLAIN ANALYZE are really powerful tools for figuring out why a query performs badly and validating that indexing you add actually improved query performance.
Thanks for this additional feedback. It sounds like we should create an XCode project from scratch to get many of the defaults and figure out how to bridge this with our current implementation.
"miss the point" feels a bit strong. Rather, I get the impression Alacritty's values don't match your own values in a terminal emulator, and that's totally OK. Historically, input latency hasn't been considered a big pain point by most users.
That said, we do have a plan[1] to address this issue and be both high throughput _and_ low-latency.
The hardest part about supporting things like this on macOS is that they often require a lot of additional code or a certain design whereas on Linux, a lot of these features are provided by the window manager.
I don't consider it contrary to the project's goals if it's something that can be done unobtrusively. Given your description, it sounds like this may be something we could support easily. I filed #1544 to track this. Thanks for the suggestion!
We tried to strike a balance between "commonly accepted as fast" terminal emulators and coverage of "commonly used" terminal emulators. Termite gets us libvte-based terminals (like gnome-terminal), urxvt is generally considered as one of the fastest, and Kitty is another well-regarded GPU-accelerated terminal emulator. On macOS, there's not nearly as many choices.
Ultimately, it would be great if we could benchmark against every terminal emulator, but that can become a very time-consuming task. If there's another emulator you feel should be included, we can consider it for future updates/benchmarks.
Thanks for this feedback! We haven't heard a ton of complaints about the input latency, and comments like this help us to prioritize issues. This has been mentioned in two discussions today, so perhaps it's time to address this.
> Skia is definitely capable of good performance, as it resolves down to OpenGL draw calls, pretty much the same as Alacritty, WebRender, and now xi-mac.
This claim is a bit surprising to me. I was under the impression Skia is an immediate mode renderer which ends up issuing a lot GL calls that could be avoided with a retained mode renderer.
The article you linked is specifically about latency. There are other factors that contribute to overall terminal experience such as high frame rate and high throughput. Once latency reaches a "good enough" level, it becomes a non issue, and frame rate and throughput remain. Alacritty excels in those areas (there's even a table in that article demonstrating Alacritty's high throughput).
There is also a plan[1] for making Alacritty's latency best-in-class.
OneSignal | DevOps, Systems, Full-Stack | San Mateo, CA | ONSITE
OneSignal provides a simple interface to push notifications, letting content creators focus on quality user engagement instead of complex implementation. Our goal is to democratize push communication for everyone from individual blogs to top tier apps.
We are looking for talented software engineers from any background. Our stack includes Rust, Ruby on Rails, React.js, PostgreSQL, and Redis. Experience with our specific tech is not required; we are simply looking for talented people with a big appetite for learning and shipping quality code.
Word of caution when reviewing this report: it doesn't take into account vblank period. If you hit a key just after a monitor refresh, you're not going to see it until the next refresh cycle which is typically up to 16ms later. This study is concerned with how long it takes to update the frame buffer rather than time-to-visible which is difficult to measure.
That said, there are plans[1] to reduce Alacritty's input latency. Though, I personally use it as a daily driver and have never felt that there was a noticeable input lag.
Once that lands, Alacritty will have similar latency to Terminal.app _and also have_ a 60 Hz refresh rate (the "smooth" feeling), low CPU usage, and much higher throughput.
We can do better in Alacritty. For those interested, I've filed a bug on our issue tracker about where this latency is coming from and what can be done: https://github.com/jwilm/alacritty/issues/673
At the end of the day, there is a trade off to be made. Terminals (or any program, really) can have 1-frame input latency (typically 1/60sec) and give up v-sync and tearing results, or they can have a worst-case 2-frame input latency with v-sync, and then you're looking at 2/60sec or ~32ms.
> Pathfinder's API is based around the concept of an atlas in order to improve batching.
And the result of a raster job is then coordinates in the Atlas?
> Especially at small sizes it's a lot more efficient to render multiple glyphs all in one go without issuing separate draw calls for each one.
Makes sense
> There's nothing preventing you from making a separate "atlas" for each glyph if you want, though you'll pay some performance cost for this.
It's not exactly an atlas then is it :P. Sorry if I wasn't clear; I was trying to understand whether the library or the application is managing the Atlas. Sounds like the library.
The blog post mentions integrating with WebRender as an alternative rasterizer on capable systems. Could performance of the GPU-based rasterizer ever get to the point that WebRender's glyph cache is no longer needed?
After glancing quickly at the code, it looks like the lorem ipsum example renders to a texture atlas. Is that part of Pathfinder or just part of that example? I'm trying to understand whether managing the altas would be up to the application or Pathfinder.
> concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable
The project initially started to be an optimized tmux renderer. It's not supposed to appeal to everybody. That said, there's a big segment of users with tiling window managers that are only blocked by not having scrollback, and we're talking about adding it. Features like tabs/splits will likely never be introduced.
> If I can find a workaround to the remote paste issue
What platform are you on that the selection copy and mouse paste isn't working? It's also possible to configure this to another keybinding if you prefer.
One of the nice things about PostgreSQL regardless of scale are the tools they provide for optimizing your application. EXPLAIN and EXPLAIN ANALYZE are really powerful tools for figuring out why a query performs badly and validating that indexing you add actually improved query performance.