jwilm

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.

I didn't know that Terminology has GPU acceleration. I would be happy to include this in the future!

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.

[1]: https://github.com/jwilm/alacritty/issues/673

Thanks for this clarification. I don't see any reason we couldn't support this given that info.

We haven't intentionally opted out of this that I know of, we just didn't start Alacritty from an XCode project on macOS.

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!

#1544: https://github.com/jwilm/alacritty/issues/1544

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.

If you want notifications on any developments here, please subscribe to this GitHub issue: https://github.com/jwilm/alacritty/issues/673

Author here; I'm happy to answer any questions!

> 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.

[1]: https://github.com/jwilm/alacritty/issues/673

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.

Specific roles and benefits can be seen on our careers page: https://onesignal.com/careers.

To apply, please send your application to [email protected].

Interested in how we leverage Rust for our application? Check out this blog post! https://onesignal.com/blog/rust-at-onesignal/

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.

[1]: https://github.com/jwilm/alacritty/issues/673

Author here; happy to answer questions.

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.

FWIW, We're working on adding native support for scrolling. Someone has actually made an attempt at it recently: https://github.com/jwilm/alacritty/pull/657

Initial testing has shown it not to (noticeably) impact perf in our highly unscientific benchmarks.

Thanks for the answers!

> 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.

How does/will Pathfinder support ligatures?

There's a known bug when using Mesa that kills performance. Hopefully we'll get it resolved soon!

I'm happy to hear you're enjoying it!

> 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.

> do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally?

I hadn't replied to this because others had already provided all of the info I have. To summarize, the author of notty[0] and I are talking about a collaboration[1]. notty has done a ton of pathfinding in this area on identifying how to add many of these features in a backwards compatible way. I'm really looking forward to see where it goes!

[0]: https://github.com/withoutboats/notty [1]: https://github.com/jwilm/alacritty/issues/51

I've heard that a few times now. For what it's worth, that's in the works!

Vulkan is not yet supported on macOS. There are plans for a Vulkan renderer, but cross-platform support will come first.

That seems completely reasonable. Not sure why I didn't consider it. PRs welcome :D

2. I don't have easy access to the high DPI scale factor, so it needs to be configured manually for now :(.

     dpi:
         x: 144.0
         y: 144.0

1. That doesn't sound good! Would you mind filing an issue?

Generally continuously, but it depends on how you scroll. If you're in `less` for example and holding the down key, you will probably see one line at a time, and it should be very smooth. It's possible with high key repeat rates that you might get multiple lines on some frames.

The tiling WM argument has basically sold me at this point. I'm expecting to open an issue about adding this feature behind a compile-time flag.