![]() There is no plan to remove the WinPTY implementation anytime soon, so if there is a user who feels impacted by the slowdown I encourage them to reach out to the community ( cdt-dev mailing list, tweet me, comment on this bug or create a bug report).Įclipse CDT has just had all its source code reformatted. I am grateful to the community’s contributions and I will happily support/test/integrate any improvements, such as the upcoming Ctrl-Click functionality that was contributed by Fabrizio Iannetti and will be available in Eclipse IDE 2021-06.īecause much of the performance slowdown is because of ConPTY itself, which is actively being developed at Microsoft I hope that Eclipse will benefit from those performance improvements over time. Therefore I plan to focus my time on other areas of the terminal, like WSL integration and bug fixes with larger impacts. I am pleased that the performance of ConPTY with JNA is close to the new dedicated Microsoft Terminal and much faster than VSCode. The code could probably be revisited because presumably the new ConPTY does not suffer from these buffering issues, and the throttling probably should not be there for non-Windows at all. However the terminal has an artificial throttle in this path that limits performance to around 0.01 MiB/s, plenty fast to type, but much slower than a performant system could be. I was going to run an Eclipse -> Shell test to make sure writes to the terminal hadn’t regressed. The above shows that the raw speed of Eclipse Terminal is very good, it simply requires the best possible PTY layer to achieve the best speeds. VSCode is dramatically slower than the rest.įull table of results based on a 10MiB write, reported in MiB/second, rounded to nearest 0.1 MiB/s:Īs a comparison, on the same machine dual-booted into Xubuntu 18.04 I ran the following 5 terminals: ConPTY is quite a bit slower, whether used in Eclipse or Windows Terminal. Short summary is that WinPTY and Windows Command are much faster than the rest. VSCode’s integrated terminal using ConPTYĪnd in each of them I ran the same Java program in 3 different shells:.Windows Terminal (from the people who wrote conpty).Windows Command – the classic terminal when you run cmd.exe for example.I used 5 terminal programs to test the performance: See the SpeedTest attachment for the source. The Java program creates a byte of configurable size and writes that all to () in one go, with some simple wall clock timing around it. I have analyzed the performance of a process running in the shell writing to stdout as fast as possible to compare various different terminal options on my Windows machine. But I wanted to make sure our use case wasn’t a problem and that there wasn’t anything else getting in the way of the terminal’s performance. In particular, while JNA is slower for some things the ease of use of JNA normally far outweighs the performance hit. One of the open questions I had was whether there would be a performance issue because of the change to ConPTY. For interfacing to ConPTY we are using JNA which is much easier to develop because all the interfacing is in the Java code. The WinPTY version in Eclipse is also quite out of date, and hard to develop as it is interfaced to by JNI.įor Eclipse 2021-06 the Eclipse CDT will be releasing a preview version of the terminal that will use ConPTY. For the last number of years, Windows 10 has a native version called Windows Pseudo Console ( ConPTY) which programs such as VSCode and Eclipse Theia have converted to using, in part because of the fundamental bugs that can’t be fixed in WinPTY. On Windows the terminal uses the amazing WinPTY library to provide a PTY as Windows did not come with one. For many years the Eclipse IDE has provided an integrated terminal (called Eclipse TM Terminal) and now maintained by the Eclipse CDT team.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |