![]() ![]() ![]() The file used was the 370KB one in “Files Open Time” tests. I used Activity Monitor to add up memory used by all its processes. String = 'abcdefghijklmnopqrstuvwxyz1234567890\n'Įach editor was launched first with a file loaded. The files’ sizes were 370KB, 3.7MB, 37MB and 370MB respectively. ![]() Files Generatingįour files contained 10k, 100k, 1m, 10m lines were generated by the following Python script. I recorded the time between the file being released and the moment when the file was full loaded. A file was dragged from Finder to its window. Files Open TimeĮach editor was launched first with a window open. I would record the time between clicking the “New Window” from the menu in the Dock (or its equivalents) and the moment when first window was full loaded. Window Open TimeĮach editor was launched first with all windows closed afterwards. I recorded the time between clicking the icon and the moment when first window was full loaded. Launch TimeĮach editor was launched from Dock by clicking the icon. macOS’s stock TextEdit was used as a reference. All programs I could see had been closed. The hardware I tested on was a MacBook Pro 2016 13-inch with Touch Bar (with 2.9 GHz Intel Core i5 CPU and 8 GB 2133 MHz LPDDR3 RAM running macOS Sierra 10.12.2). So I want to do a test and find out their performance difference. Visual Studio is also built using Web Technology like Atom, but reviewers said it is faster. These days, I Googled “Sublime Text vs Atom 2016”, trying to see if Atom has significant improvement when I found Visual Studio Code. The reason I sticked with Sublime Text was performance: Atom was slow, even after when Atom 1.0 was announced. I tried Atom one or two year ago and I was impressed by its active community (GitHub! I love GitHub). VSCode agreed, and asked me to expand my PR.īut overall, I think though now painful for some, the change is really a benefit to most, and the right default behavior for all going forward.Speaking of text editor, I have been using Sublime Text for around 3 years, and I have no issues with it. The idea is to make docstring comments, which are really more in the category of comments, not strings, be treated by the syntax highlighters the same as comments, not strings. and screenshots in my link above, everyone can tweak their syntax highlighters as desired.īy the way, I am the one who created that PR, and VSCode's maintainers are the ones who requested that I massively expand my PR to cover all docstrings, not just Python docstrings, and all syntax highlighters, not just the Monokai syntax highlighter I was using. Use this technique to customize other scopes and colors to your liking, or to see what colors and formatting other scopes currently have if you want to copy also has a great answer to this question. In my link above, I explain how to use the token and scope inspector, and then I say: How to subdue Python block comment strings in VSCode in order to look like Sublime Text's Monokai It contains info about finding the names and colors of sections you like and how to change the ones you don't: To some extent, the problem is incurable without the VS Code team updating how they handle this semantic difference: it will incorrectly highlight docstrings and block comments identically, so the answer is to choose between wrong behaviors.įor anyone wishing to customize your theme to go back to how it was for your syntax highlighter, read my answer here to learn how to do that. There is a semantic, non-syntactic difference between these in the Python language. The task remains to fix it back to the way it was before this change.Įdit 2: VS Code does not seem to have a way to distinguish between block comments and docstrings. This guy decided to just change the theme color. Using a venv or not has no effect.Īny idea what happened or how to fix this?Įdit: I found the culprit. Disabling and/or re-enabling extensions has no effect with the exception that disabling the Python extension removes several colors from syntax highlighting, but not the dark green. Manually modifying the theme json file does nothing, and this nasty color is not in any of the theme files. Toggling between themes does not restore the original color. After I restarted, the "Dark modern" theme was still selected, but now docstrings are an ugly, dark green color. Before I restarted VS Code, I had the "Dark modern" theme selected, and Python docstrings were exactly the same color as other strings. Nothing I do with themes seems to do anything. ![]()
0 Comments
Leave a Reply. |