text:
Loading large file with many lines sometimes hangs or crashes the editor

File that has 140000 lines can reproduce this issue.
Sublime Text 3 release version has no this problem.

Duplicate https://github.com/atom/atom/issues/979

Thanks @OmgImAlexis.

I'm actually not sure if this is a dupe of #979 – @fewspider mentions that this happens with a file with 140,000 lines, rather than a single really long line.
@fewspider Can you reproduce this by completely quitting Atom and restarting it in in safe mode? (atom --safe)

@mnquintana My atom version is 1.0.15, atom --safe is OK👌. My file is a sql file, the syntax highlighting is not working,when atom or atom --safe. Just a guess, the syntax highlighting problem happens in large file.

Sounds like being related to syntax highlighting and thus sounds like a duplicate of #6642

I can confirm, to this very day, that Atom (1.8.0 safe mode, OSX and Windows) hangs forever or crashes (it did both today) when you try and open a 1MB XML file with only two lines.

@alexchandel That's https://github.com/atom/atom/issues/979 – this issue is only for large files with many lines causing hangs.

@mnquintana Ah of course. For the record, neither the UTF-8 nor the UTF-16LE file I tried crashed Atom when I threw a newline after every XML tag (33588 lines total). It seems Atom only hangs or crashes (depending on the file encoding, funnily enough) when the lines are long (1MB in this case).
That's still atrocious behavior though. It completely defeats the point of using Atom to beautify text if Atom crashes trying to open the ugly file.

Also experiencing crashed when opening large files. I typically need to open GAMS listing files (.lst) which can run from several MBs for a small model run to > 100 MB.

Me too - large XML or JSON files, Atom 1.9.8 on Windows 7, safe mode or not. The current example is a 14 MB json file with 300k lines, pretty-printed with no line more than 70 characters long.
Here's the bit from the console output that looks most relevant:
Security context: 2985BF09 <String[7]: file://>
    2: buildSpatialScreenLines [C:\Users\****\AppData\Local\atom\app-1.9.8\resources\app.asar\node_modules\text-buffer\lib\display-layer.js:~532] [pc=1F5FC89B] (this=3C45DC6D <a DisplayLayer with map 2C0117C1>,startBufferRow=0,endBufferRow=303672)
    3: reset [C:\Users\****\AppData\Local\atom\app-1.9.8\resources\app.asar\node_modules\text-buffer\lib\display-layer.js:223] [pc=1F5153F...

I just had the same exact problem as OP, tried opening a ~11MB file and the editor took several minutes to open it - then scrolling would be extremely slow as well.
Emacs and Notepad++ handled the file (and other similar ones) with no problems

It crashes for me too, in my case with a 5MB+ log file with around 20K lines, some of them with 100K+ characters. This file was opened without trouble with Notepad++ and vim.

I get a consistent crash within 15 seconds after trying to open a 50 MB json file.

macOS 10.12: Atom crashed when I copied or loaded a larger Base64 and JavaScript file.
Prerequisites

Can you reproduce the problem in safe mode?

Yes, but it also crashed when I loaded a larger JavaScript file. So it is not responding.

Are you running the latest version of Atom?

Yes, it is the latest version in my Mac.

Did you check the debugging guide?

Yes. Check the debugging:
Atom        : 1.10.2
Electron.  : 0.37.8
Chrome    : 49.0.2623.75
Node         : 5.10.0

Did you check the FAQs on Discuss?

Yes, I did. But my problem isn't related to any subject found in the FAQs.

Are you reporting to the correct repository?

My problem isn't related to a package.

Did you perform a cursory search to see if your bug or enhancement is already reported?

Yes, I did, it is also related:
https://github.com/atom/atom/issues/8864
For more information on how to write a good [bug report]:
Process:               Atom Helper [902]
Path:                  /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper
Identifier:            Atom Helper
Version:               1.10.2 (1.10.2)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Atom [727]
User ID:               501

Date/Time:             2016-10-07 10:02:42.654 -0300
OS Version:            Mac OS X 10.12 (16A323)
Report Version:        12
Anonymous UUID:        43A71557-C43F-7D46-22C5-D5F533564107

Time Awake Since Boot: 2400 seconds

System Integrity Protection: disabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000000009e0

VM Regions Near 0x9e0:
-->
    __TEXT                 000000010f682000-000000010f683000 [    4K] r-x/rwx SM=COW  /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libnode.dylib                 	0x0000000113e19a4d v8::internal::GlobalHandles::Node::Release() + 173
1   com.github.electron.framework 	0x000000010f756416 0x10f68a000 + 836630
2   libsystem_c.dylib             	0x00007fffbf792198 __cxa_finalize_ranges + 332
3   libsystem_c.dylib             	0x00007fffbf7924d2 exit + 55
4   libdyld.dylib                 	0x00007fffbf6fd25c start + 8

Thread 1:
0   libsystem_kernel.dylib        	0x00007fffbf82c4e6 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x00007fffbf9137c5 _pthread_wqthread + 1426
2   libsystem_pthread.dylib       	0x00007fffbf913221 start_wqthread + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x00007f8173812a00  rbx: 0x0000000000000000  rcx: 0xfffffffffffff460  rdx: 0x00007f8172024600
  rdi: 0x00007f81720251a0  rsi: 0x00004a0000000000  rbp: 0x00007fff5057d750  rsp: 0x00007fff5057d740
   r8: 0x00007fffc83e10c8   r9: 0x000000000001a65f  r10: 0x00007fffc83e10d0  r11: 0xffffffff00000000
  r12: 0x00007f8172003400  r13: 0x0000000000000002  r14: 0x00007f8171f106c0  r15: 0x00000000000002a0
  rip: 0x0000000113e19a4d  rfl: 0x0000000000010207  cr2: 0x00000000000009e0

Logical CPU:     3
Error Code:      0x00000004
Trap Number:     14

Binary Images:
       0x10f682000 -        0x10f682fff +com.github.atom.helper (1.10.2 - 1.10.2) <F457A1AF-91C0-31F3-99BA-70A2DED3571B> /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper
       0x10f68a000 -        0x112f3450f +com.github.electron.framework (0) <837BC71C-6DE6-33A5-808D-643FEC92FC83> /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
       0x1136aa000 -        0x1136bfff7 +com.github.Squirrel (1.0 - 1) <C39DE518-902E-3EBE-B1A6-B4E7AE668521> /Applications/Atom.app/Contents/Frameworks/Squirrel.framework/Versions/A/Squirrel
       0x1136df000 -        0x113742ff7 +org.reactivecocoa.ReactiveCocoa (1.0 - 1) <701B20DE-3ADD-3643-B52A-E05744C30DB3> /Applications/Atom.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/A/ReactiveCocoa
       0x1137b9000 -        0x1137cdfff +org.mantle.Mantle (1.0 - ???) <31915DD6-48E6-3706-A076-C9D4CE17F4F6> /Applications/Atom.app/Contents/Frameworks/Mantle.framework/Versions/A/Mantle
       0x1137e5000 -        0x1144f8fff +libnode.dylib (0) <3AF9018F-73A7-355F-91E1-E3612A113C88> /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib
       0x114949000 -        0x114b82fef +libffmpeg.dylib (0) <6F49E894-75FB-39E3-B530-B09F13B1EA98> /Applications/Atom.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib
       0x114d15000 -        0x114d53fff  com.apple.audio.midi.CoreMIDI (1.10 - 88) <81393A2D-184B-3847-802A-B8BCF6D1080C> /System/Library/Frameworks/CoreMIDI.framework/Versions/A/CoreMIDI
       0x114d7e000 -        0x114d97ffb  libexpat.1.dylib (15) <617B8B7A-A0AB-37D6-AFCA-F90F7F14E455> /usr/lib/libexpat.1.dylib
       0x117de3000 -        0x117de7fff +spellchecker.node (???) <4F8A96B4-08B2-370A-8146-5319934D1656> /Applications/Atom.app/Contents/Resources/app.asar.unpacked/node_modules/spellchecker/build/Release/spellchecker.node
       0x11da0a000 -        0x11da471c7  dyld (421.1) <A525EAEA-AF86-30C2-B360-3D093B4F0828> /usr/lib/dyld
    0x7fffa6e48000 -     0x7fffa7006fff  com.apple.avfoundation (2.0 - 1183.3) <E6DCAB50-ECD4-3645-8A93-D14F14092DC4> /System/Library/Frameworks/AVFoundation.framework/Versions/A/AVFoundation
    0x7fffa7007000 -     0x7fffa70aaff7  com.apple.audio.AVFAudio (1.0 - ???) <18E472FC-5AD7-33B8-8D46-49D5AC2DB13A> /System/Library/Frameworks/AVFoundation.framework/Versions/A/Frameworks/AVFAudio.framework/Versions/A/AVFAudio
    0x7fffa713d000 -     0x7fffa713dfff  com.apple.Accelerate (1.11 - Accelerate 1.11) <BDDB2053-BB24-34E4-A452-50D1260BF672> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fffa7156000 -     0x7fffa7796fe3  com.apple.vImage (8.1 - ???) <6CC22156-EC5C-3DC3-8132-41376F090B08> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fffa7797000 -     0x7fffa795efef  libBLAS.dylib (1185) <0D55CF73-6DBD-3D15-B500-189479638551> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fffa795f000 -     0x7fffa7976fff  libBNNS.dylib (14) <43A9B06E-3C21-3CE6-B0C1-99DA172DEEB0> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
    0x7fffa7977000 -     0x7fffa7d82fff  libLAPACK.dylib (1185) <E7AE9C48-6E42-3EB7-A257-D48E0CB48D00> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fffa7d83000 -     0x7fffa7d99fff  libLinearAlgebra.dylib (1185) <08F00EFB-B477-3421-906E-3D364E607E6A> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fffa7d9a000 -     0x7fffa7da0fff  libQuadrature.dylib (3) <120F6228-A3D4-3184-89D7-785ADC2AC715> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
    0x7fffa7da1000 -     0x7fffa7db4ff7  libSparseBLAS.dylib (1185) <912E3D25-27C0-3245-B64C-3CAD43A5D633> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
    0x7fffa7db5000 -     0x7fffa7f02ff7  libvDSP.dylib (600) <87EF1D0A-1F85-31DD-AD8F-AB31E7D8E73B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fffa7f03000 -     0x7fffa7fbafff  libvMisc.dylib (600) <F6EA539E-0A90-3F8A-9ECA-001E46394E29> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fffa7fbb000 -     0x7fffa7fbbfff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <B4B785D8-CB43-3E5D-AE81-1F27885AA112> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fffa8278000 -     0x7fffa8f4fff3  com.apple.AppKit (6.9 - 1504) <5524F97F-FB11-3556-8AC4-FF634C6CCCB7> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    0x7fffa8f61000 -     0x7fffa8f61fff  com.apple.ApplicationServices (48 - 48) <3E1395EA-C661-3318-9B87-9857BB81021B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fffa8f62000 -     0x7fffa8fd0ff7  com.apple.ApplicationServices.ATS (377 - 422) <521E41BF-D495-3233-B6BF-C0B83DD1A8C0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
    0x7fffa906a000 -     0x7fffa9198fff  libFontParser.dylib (194) <CDC6A0AA-E6AC-315B-AFBF-011F64548911> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
    0x7fffa9199000 -     0x7fffa91e3fff  libFontRegistry.dylib (196) <3B8B0E78-2B30-3F18-B7D3-BE4E96F6BAF3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fffa92de000 -     0x7fffa9388ff7  com.apple.ColorSync (4.12.0 - 502) <C86F8032-83DD-34EB-A4CB-87E96F25CF1C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
    0x7fffa9389000 -     0x7fffa93d9fff  com.apple.HIServices (1.22 - 589) <3167EF9C-F121-39EF-AAE2-7700E7128426> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fffa93da000 -     0x7fffa93e9ff3  com.apple.LangAnalysis (1.7.0 - 1.7.0) <47D1A017-91A4-37F3-93E0-3923CD6ED2DE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
    0x7fffa93ea000 -     0x7fffa9437fff  com.apple.print.framework.PrintCore (12 - 491) <B7CC15C1-AF50-37F3-8AF6-65F8CDC323F0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
    0x7fffa9438000 -     0x7fffa9473fff  com.apple.QD (3.12 - 310) <8F718290-DD82-36CE-9AF0-EFB6D31A49F4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fffa9474000 -     0x7fffa947fff7  com.apple.speech.synthesis.framework (6.0.15 - 6.0.15) <23EA6076-ECDF-3A50-81E7-3CE6451DC8C4> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
    0x7fffa9480000 -     0x7fffa968cfff  com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <EDDC86C8-92F3-34C6-A5C1-A176ADA724C3> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fffa968d000 -     0x7fffa968dfff  com.apple.audio.units.AudioUnit (1.14 - 1.14) <AA9DB0D2-3B2F-3366-B451-DD9E89038F6F> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
    0x7fffa97f6000 -     0x7fffa9b79fff  com.apple.CFNetwork (807.0.4 - 807.0.4) <A338A213-4FFF-3317-B4DB-84735C63C507> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fffa9b93000 -     0x7fffa9b93fff  com.apple.Carbon (154 - 157) <AB71A31F-5B15-3BF5-8532-591EACD07B21> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fffa9b94000 -     0x7fffa9b97fff  com.apple.CommonPanels (1.2.6 - 98) <DDA2DF0B-86E7-34B6-B688-D7371DBC8A63> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
    0x7fffa9b98000 -     0x7fffa9e9bfff  com.apple.HIToolbox (2.1.1 - 855) <AA4E2957-6B2D-3822-881C-0F64222F9578> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
    0x7fffa9e9c000 -     0x7fffa9e9fff7  com.apple.help (1.3.5 - 49) <27C5F9FE-838F-3807-A4AC-D99470185B10> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
    0x7fffa9ea0000 -     0x7fffa9ea5fff  com.apple.ImageCapture (9.0 - 9.0) <E3E757FD-4060-33A4-A2AC-85EFBD987FCE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
    0x7fffa9ea6000 -     0x7fffa9f3dff3  com.apple.ink.framework (10.9 - 219) <B44BA36D-7549-3EB2-8CF6-E171885194FB> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
    0x7fffa9f3e000 -     0x7fffa9f58fff  com.apple.openscripting (1.7 - 172) <B204BF70-C4AA-3699-8493-66E6645A92A8> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
    0x7fffa9f59000 -     0x7fffa9f5aff3  com.apple.print.framework.Print (12 - 267) <CA7E9448-0903-34C8-AAF6-9070B52BF70E> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
    0x7fffa9f5b000 -     0x7fffa9f5dff7  com.apple.securityhi (9.0 - 55006) <856F4FB9-AAF2-3FC2-BE19-E7AB494232CC> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
    0x7fffa9f5e000 -     0x7fffa9f64ff7  com.apple.speech.recognition.framework (6.0.1 - 6.0.1) <A20B0F7B-C32A-3FF1-BB75-BAC0EE4EF889> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
    0x7fffaa044000 -     0x7fffaa044fff  com.apple.Cocoa (6.11 - 22) <5EEB0A26-F1C2-3D57-8441-52C0B80C2A6A> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    0x7fffaa177000 -     0x7fffaa207ff7  com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <0352D931-596B-3AFE-B5C6-5925CF9F870E> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fffaa208000 -     0x7fffaa21bff3  com.apple.CoreBluetooth (1.0 - 1) <73A2B185-70E4-3535-A653-E1BC74584E55> /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
    0x7fffaa21c000 -     0x7fffaa516fff  com.apple.CoreData (120 - 752.2) <51AB540E-01AE-3207-8DE5-3E912FA9B5DF> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
    0x7fffaa517000 -     0x7fffaa5a3fff  com.apple.CoreDisplay (1.0 - 1) <F10E2F1A-FA51-3256-BCCE-34FF30AB1E3A> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay
    0x7fffaa5a4000 -     0x7fffaaa37ff7  com.apple.CoreFoundation (6.9 - 1348.1) <2A35BE4F-BA5B-3C22-BCF1-CFBBA2786081> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fffaaa38000 -     0x7fffab0d8ff7  com.apple.CoreGraphics (2.0 - 1070) <765D6A92-48AE-3CBB-9967-61300D715F1F> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fffab0d9000 -     0x7fffab318ff7  com.apple.CoreImage (12.0.0 - 451) <84C71E9C-5231-342F-94B1-2BB6860E8AD3> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
    0x7fffab376000 -     0x7fffab426ff7  com.apple.CoreMedia (1.0 - 1903.7) <5FE3B4CC-EC1A-38FE-96FA-FFD419229F3E> /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia
    0x7fffab427000 -     0x7fffab472ff7  com.apple.CoreMediaIO (801.0 - 4922) <2813BA18-E24C-3CFB-8B34-73575DFDF0BC> /System/Library/Frameworks/CoreMediaIO.framework/Versions/A/CoreMediaIO
    0x7fffab473000 -     0x7fffab473fff  com.apple.CoreServices (775.8 - 775.8) <C36F7F47-D585-32F2-8A6F-7711935CDFD6> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fffab474000 -     0x7fffab4c5ff7  com.apple.AE (712 - 712) <0EF17D7E-6BA4-3555-BC38-9BD0CC5B82A3> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fffab4c6000 -     0x7fffab7a1fff  com.apple.CoreServices.CarbonCore (1159 - 1159) <837B7ECF-7E62-3210-988C-63D7AB4EAA88> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fffab7a2000 -     0x7fffab7d5fff  com.apple.DictionaryServices (1.2 - 274) <302B8678-D057-3CF8-ACA7-7424A4A6A00A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fffab7d6000 -     0x7fffab7deffb  com.apple.CoreServices.FSEvents (1230 - 1230) <8836E7D0-844F-36F9-9601-B630BB82336B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
    0x7fffab7df000 -     0x7fffab94afff  com.apple.LaunchServices (775.8 - 775.8) <6E7CE1DA-27A4-3B48-A8E3-F2AA868ADD7C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fffab94b000 -     0x7fffab9fbffb  com.apple.Metadata (10.7.0 - 1075) <9EDF10CF-1755-346A-A3C9-97642C443A58> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fffab9fc000 -     0x7fffaba5bfff  com.apple.CoreServices.OSServices (775.8 - 775.8) <FCF1334F-D2D7-3C5A-A8FE-C173C5EDE586> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fffaba5c000 -     0x7fffabaccfff  com.apple.SearchKit (1.4.0 - 1.4.0) <F1B3EF8D-E820-317C-AC7F-8F056C246874> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fffabacd000 -     0x7fffabb13ff7  com.apple.coreservices.SharedFileList (38 - 38) <6C5A3FBB-9502-3725-AC3A-AE7B1528BBD4> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
    0x7fffabba0000 -     0x7fffabcebff7  com.apple.CoreText (352.0 - 544) <064B53E8-CD5A-3D1B-81DF-498A659FC20A> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fffabcec000 -     0x7fffabd21fff  com.apple.CoreVideo (1.8 - 234.0) <48C31E93-87C2-31F4-97E7-9E54C1EA8E7D> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fffabd22000 -     0x7fffabd93ffb  com.apple.framework.CoreWLAN (11.0 - 1200.25.1) <F46EF4A2-C348-3F76-A1C2-B8A84C17FE2B> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN
    0x7fffabe8e000 -     0x7fffabe93fff  com.apple.DiskArbitration (2.7 - 2.7) <566D5C06-13E8-3638-B2EC-2B834D5F04F1> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fffac022000 -     0x7fffac3c9ffb  com.apple.Foundation (6.9 - 1349) <08A463B1-296E-3AC1-B8D3-01A75B0785A8> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fffac3f5000 -     0x7fffac426ff3  com.apple.GSS (4.0 - 2.0) <B30A0B99-AFDE-3BF8-A04F-761A75A6A3B1> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
    0x7fffac4da000 -     0x7fffac57dffb  com.apple.Bluetooth (5.0.0 - 5.0.0f18) <00417775-D746-32C1-9598-CE8716DFBECD> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth
    0x7fffac57e000 -     0x7fffac613fff  com.apple.framework.IOKit (2.0.2 - 1324.1.7) <10BDCD1E-0463-3C53-BF11-C9A0919C1588> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fffac614000 -     0x7fffac61affb  com.apple.IOSurface (152 - 152) <558D4451-2D9D-3D47-B3A5-E7C18DF53F1B> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fffac66e000 -     0x7fffac7c7ff7  com.apple.ImageIO.framework (3.3.0 - 1570.1) <6B0177F3-A7BE-30D7-B075-7117E2C28A5F> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fffac7c8000 -     0x7fffac7ccfff  libGIF.dylib (1570.1) <AE06146E-C4B3-3088-B6BC-569DDFCD8D77> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fffac7cd000 -     0x7fffac8befff  libJP2.dylib (1570.1) <6D268C9D-309B-3098-BBCF-8A1B98DBBEE9> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
    0x7fffac8bf000 -     0x7fffac8e2fff  libJPEG.dylib (1570.1) <7EFA7A91-06C8-329E-AA3D-CF6DB2220A5A> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fffac8e3000 -     0x7fffac909fff  libPng.dylib (1570.1) <AF8292B6-2564-30D4-8860-6B0C9D0E1405> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fffac90a000 -     0x7fffac90cff3  libRadiance.dylib (1570.1) <B0256EB7-7F87-39FD-BD35-83577F4FE7EC> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fffac90d000 -     0x7fffac966fff  libTIFF.dylib (1570.1) <F1F0B7C6-388F-35E4-87CF-816CEE8B0E00> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fffad52d000 -     0x7fffad546ff7  com.apple.Kerberos (3.0 - 1) <49DCBE1A-130C-3FBF-AAEA-AF9A518913AC> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fffad7c0000 -     0x7fffad7c6fff  com.apple.MediaAccessibility (1.0 - 97.1.1) <EE1825C7-3B58-32F8-9F5F-B7172452BB01> /System/Library/Frameworks/MediaAccessibility.framework/Versions/A/MediaAccessibility
    0x7fffad7dc000 -     0x7fffadd29fff  com.apple.MediaToolbox (1.0 - 1903.7) <37363406-481C-3DDD-A61F-9E2153A3660B> /System/Library/Frameworks/MediaToolbox.framework/Versions/A/MediaToolbox
    0x7fffadd2a000 -     0x7fffadd81ff7  com.apple.Metal (85.82 - 85.82) <CDC847A6-F1F6-3661-8981-180F2A485092> /System/Library/Frameworks/Metal.framework/Versions/A/Metal
    0x7fffae497000 -     0x7fffae49ffff  com.apple.NetFS (6.0 - 4.0) <6614F9B8-0861-338B-8FF0-8E402F96141C> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fffae844000 -     0x7fffae892ff3  com.apple.opencl (2.8.6 - 2.8.6) <DA3164B7-EB48-3F68-A40F-CD9B433E385F> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fffae893000 -     0x7fffae8acffb  com.apple.CFOpenDirectory (10.12 - 194) <BDD22B3E-4149-366A-A974-942280861DD4> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fffae8ad000 -     0x7fffae8b8ff7  com.apple.OpenDirectory (10.12 - 194) <E1125140-E42C-369C-8DC8-D0935767B275> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fffae8b9000 -     0x7fffae8bbfff  libCVMSPluginSupport.dylib (12.4.2.1) <5A7CBDC5-297E-30E0-8951-2F3DAFD0027E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
    0x7fffae8bc000 -     0x7fffae8bfff7  libCoreFSCache.dylib (148) <3297ACE0-B9D8-3821-8685-2619B4234621> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
    0x7fffae8c0000 -     0x7fffae8c3fff  libCoreVMClient.dylib (148) <B4299590-02BA-3130-98EA-A2D3A53852E1> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fffae8c4000 -     0x7fffae8ccffb  libGFXShared.dylib (12.4.2.1) <3CBE90E5-6472-3C4C-825D-7567A5652115> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fffae8cd000 -     0x7fffae8d8fff  libGL.dylib (12.4.2.1) <E68C6C85-3B98-3525-9279-3296977FBF9F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fffae8d9000 -     0x7fffae915ff7  libGLImage.dylib (12.4.2.1) <50C7DE05-73CB-3D21-BB93-31C384EB6199> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fffaea8d000 -     0x7fffaeacdff3  libGLU.dylib (12.4.2.1) <D5DB68EC-751F-34D1-BCEB-2B86D560E243> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fffaf435000 -     0x7fffaf443fff  com.apple.opengl (12.4.2 - 12.4.2) <06F5BF0B-BD03-361D-9D7B-626517E4F761> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fffaf6ac000 -     0x7fffaf7f3ff7  com.apple.QTKit (7.7.3 - 2974) <DD63A171-2DE6-3210-89B0-BD5991539755> /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit
    0x7fffb0154000 -     0x7fffb034eff7  com.apple.QuartzCore (1.11 - 449.39) <B6BEEBAC-2923-3BA6-8DBD-621A2B0E51C1> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fffb08b4000 -     0x7fffb0bcffff  com.apple.security (7.0 - 57740.1.18) <AF5E42F1-B513-3410-A5BE-1EC9CBAF8452> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fffb0bd0000 -     0x7fffb0c46ff7  com.apple.securityfoundation (6.0 - 55132.1.1) <259D4B70-0F8C-3818-99E7-3EBEAA18DE1B> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fffb0c70000 -     0x7fffb0c73ff3  com.apple.xpc.ServiceManagement (1.0 - 1) <6A9EA339-BB6A-3DD9-BF08-00B8C0262839> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fffb0ff8000 -     0x7fffb1069ff7  com.apple.SystemConfiguration (1.14 - 1.14) <C7F21776-2CCE-327B-B155-7A5948277BD6> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fffb106a000 -     0x7fffb1415ff7  com.apple.VideoToolbox (1.0 - 1903.7) <C0044876-9800-3CCA-B7D3-50B92077EF4D> /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox
    0x7fffb3677000 -     0x7fffb3692ff3  com.apple.AppContainer (4.0 - 307.1.1) <05373DD5-5892-3542-B178-C140F1AB6886> /System/Library/PrivateFrameworks/AppContainer.framework/Versions/A/AppContainer
    0x7fffb3693000 -     0x7fffb36a0ff3  com.apple.AppSandbox (4.0 - 307.1.1) <20324EFC-70DC-389D-9C27-37DCAA7E07CC> /System/Library/PrivateFrameworks/AppSandbox.framework/Versions/A/AppSandbox
    0x7fffb36a1000 -     0x7fffb36c3ffb  com.apple.framework.Apple80211 (12.0 - 1200.33) <06F8EA45-5E43-3744-BF41-BA86B8BBB5CF> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211
    0x7fffb36c4000 -     0x7fffb36d3fdb  com.apple.AppleFSCompression (88 - 1.0) <B6E2148F-BFBF-3F1B-A7DF-0F39190B4C20> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fffb37bb000 -     0x7fffb384697f  com.apple.AppleJPEG (1.0 - 1) <B4C3209B-58A5-359F-A898-F61B6C40E5E9> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG
    0x7fffb3883000 -     0x7fffb38d5fff  com.apple.AppleVAFramework (5.0.34 - 5.0.34) <193400A6-B326-3911-BB4F-6C49C1E5FA8F> /System/Library/PrivateFrameworks/AppleVA.framework/Versions/A/AppleVA
    0x7fffb3c62000 -     0x7fffb3ce0ff7  com.apple.backup.framework (1.8 - 1.8) <E2888B63-F43C-367F-B23F-7D9F9BD64401> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
    0x7fffb48fa000 -     0x7fffb4921ffb  com.apple.ChunkingLibrary (172 - 172) <83E91936-305D-32A4-A256-5582B96B1852> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
    0x7fffb5241000 -     0x7fffb524affb  com.apple.CommonAuth (4.0 - 2.0) <D9958C57-9E97-33F5-A21C-B454FDB11548> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fffb53cb000 -     0x7fffb57a8fe7  com.apple.CoreAUC (224.0.0 - 224.0.0) <8DF6075A-0711-33A9-9031-6FDA22E85C4F> /System/Library/PrivateFrameworks/CoreAUC.framework/Versions/A/CoreAUC
    0x7fffb57a9000 -     0x7fffb57d9fff  com.apple.CoreAVCHD (5.9.0 - 5900.4.1) <5E1B0512-E50B-3534-99EF-AD15E601877A> /System/Library/PrivateFrameworks/CoreAVCHD.framework/Versions/A/CoreAVCHD
    0x7fffb5966000 -     0x7fffb5977fff  com.apple.CoreEmoji (1.0 - 40) <F3D73BF8-6D48-3B1F-BBE6-EE927E725E92> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
    0x7fffb5a2c000 -     0x7fffb5a42fff  com.apple.CoreMediaAuthoring (2.2 - 955) <3B877988-3823-3A84-A083-CE0B5B54F791> /System/Library/PrivateFrameworks/CoreMediaAuthoring.framework/Versions/A/CoreMediaAuthoring
    0x7fffb5c50000 -     0x7fffb5c80ff3  com.apple.CoreServicesInternal (276 - 276) <CCB21255-89DC-3F53-A6D6-8FA8F693C837> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
    0x7fffb5f09000 -     0x7fffb5f93fff  com.apple.CoreSymbolication (61050) <BAC8D20F-4DC6-32EE-91FE-BF08E930420A> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
    0x7fffb5f94000 -     0x7fffb60cefef  com.apple.coreui (2.1 - 424.1) <B9B92DB5-1C6C-306F-BD29-B1F82EC95283> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
    0x7fffb60cf000 -     0x7fffb616effb  com.apple.CoreUtils (4.3 - 430.70) <87BEB880-3D71-3251-B51E-FF0A42DFC065> /System/Library/PrivateFrameworks/CoreUtils.framework/Versions/A/CoreUtils
    0x7fffb61be000 -     0x7fffb6223ff3  com.apple.framework.CoreWiFi (12.0 - 1200.25.1) <D7C870BE-55DE-34AF-8941-D42696D505B1> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi
    0x7fffb6224000 -     0x7fffb622ffff  com.apple.CrashReporterSupport (10.12 - 815) <10C3797E-DD63-303B-B901-1C52A502D2F8> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
    0x7fffb62d5000 -     0x7fffb634cff3  com.apple.datadetectorscore (7.0 - 539) <C3F6F52B-A1AD-36FA-9BF9-C8D0E147F0A3> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
    0x7fffb6386000 -     0x7fffb63c5fff  com.apple.DebugSymbols (137 - 137) <B229F3F7-250B-3151-8048-CEA7BF80FA52> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
    0x7fffb63c6000 -     0x7fffb63c8fff  com.apple.desktopservices (1.11 - 1.11) <3B32A105-49C1-33CC-8293-CBA1C49EFFC6> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
    0x7fffb63c9000 -     0x7fffb64daff7  com.apple.desktopservices (1.11 - 1.11) <494E239D-706F-350B-9481-2A8ECEEDBD8B> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A_/DesktopServicesPriv
    0x7fffb67a5000 -     0x7fffb6bd6ff7  com.apple.vision.FaceCore (3.3.2 - 3.3.2) <DEB42099-6927-332C-8D3E-D45096318D25> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
    0x7fffb7f0f000 -     0x7fffb7f0ffff  libmetal_timestamp.dylib (600.0.48.25) <348D32E6-AD49-36DC-A0DE-5A44B2699FFA> /System/Library/PrivateFrameworks/GPUCompiler.framework/libmetal_timestamp.dylib
    0x7fffb81d9000 -     0x7fffb81f5ff7  com.apple.GenerationalStorage (2.0 - 259) <43D40063-BD46-3008-8992-FF092B7C9A58> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
    0x7fffb88e7000 -     0x7fffb895dfff  com.apple.Heimdal (4.0 - 2.0) <18C127D7-9C61-3C5B-8C6F-7953760D2674> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
    0x7fffb8f6f000 -     0x7fffb8f76ffb  com.apple.IOAccelerator (288.13 - 288.13) <F77E27C3-20DD-3CE5-9D0A-6C89A997080E> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator
    0x7fffb8f78000 -     0x7fffb8f8cff3  com.apple.IOPresentment (1.0 - 25) <40934217-996A-3DDB-A8C4-484CA0F0222B> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment
    0x7fffb8f8d000 -     0x7fffb8fafff7  com.apple.IconServices (74.1 - 74.1) <F7B83970-4A72-3186-BBB3-90FA86C3E263> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
    0x7fffb904a000 -     0x7fffb905aff3  com.apple.IntlPreferences (2.0 - 216) <43FFAB0C-4124-3231-B0CB-137CCB0A53AF> /System/Library/PrivateFrameworks/IntlPreferences.framework/Versions/A/IntlPreferences
    0x7fffb9091000 -     0x7fffb9245fff  com.apple.LanguageModeling (1.0 - 123) <10152D7F-C7C0-34AA-A295-D712D16C76E6> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fffb987c000 -     0x7fffb987ffff  com.apple.Mangrove (1.0 - 1) <05039E9F-9C07-375B-A940-D90D455A2EC2> /System/Library/PrivateFrameworks/Mangrove.framework/Versions/A/Mangrove
    0x7fffb9adb000 -     0x7fffb9b53fef  com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <FAFA0DF5-4226-3867-A2E2-CAB889DC4490> /System/Library/PrivateFrameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders
    0x7fffb9cd5000 -     0x7fffb9cfbfff  com.apple.MultitouchSupport.framework (367.6 - 367.6) <32D8588A-29BD-3A23-92B2-05C013DA5BC5> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fffb9da8000 -     0x7fffb9db2fff  com.apple.NetAuth (6.0 - 6.0) <D57D5888-0290-3295-A1C4-D673D4DCB497> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fffba553000 -     0x7fffba594ff7  com.apple.PerformanceAnalysis (1.145 - 145) <9DF1FCCC-7EBF-3213-B77A-0C3D3B7CF7AF> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
    0x7fffbac24000 -     0x7fffbac3efff  com.apple.ProtocolBuffer (1 - 249) <D8B7694B-B598-3728-8583-9C4CC0F05B64> /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer
    0x7fffbac58000 -     0x7fffbac7bff3  com.apple.RemoteViewServices (2.0 - 124) <280DB828-4613-3DF8-ACBA-C91989B64347> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
    0x7fffbb8aa000 -     0x7fffbb8adff7  com.apple.SecCodeWrapper (4.0 - 307.1.1) <64F951CB-A975-32F0-BC60-1E839E607FCB> /System/Library/PrivateFrameworks/SecCodeWrapper.framework/Versions/A/SecCodeWrapper
    0x7fffbb93b000 -     0x7fffbb9b6fff  com.apple.Sharing (659.1.6 - 659.1.6) <C217107C-CD4B-311D-9FBA-7435B1F6186F> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
    0x7fffbb9d7000 -     0x7fffbbc38ff3  com.apple.SkyLight (1.600.0 - 100) <F0B08B4C-8550-3241-8128-F7601E60BDEB> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
    0x7fffbbe12000 -     0x7fffbbe1efff  com.apple.SpeechRecognitionCore (3.0.15 - 3.0.15) <BE386037-4B61-341F-80E2-5D8B5B50C8BC> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore
    0x7fffbc501000 -     0x7fffbc56dff3  com.apple.Symbolication (61080.2) <0F183B36-0BCF-3330-8C68-4A521A142919> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
    0x7fffbc964000 -     0x7fffbc96aff7  com.apple.TCC (1.0 - 1) <CEE9F9F9-2A24-3F60-BE73-4703D85E307C> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fffbc9f6000 -     0x7fffbcba9ff3  com.apple.TextureIO (1.31 - 1.31) <9E6E91C7-76DC-3C12-9629-494084792476> /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO
    0x7fffbcc1f000 -     0x7fffbcdaeffb  com.apple.UIFoundation (1.0 - 489) <0CD14719-FC52-3AC5-87EF-775437927990> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
    0x7fffbdce0000 -     0x7fffbdce6fff  com.apple.XPCService (2.0 - 1) <BC3FCE26-6219-3316-949F-37F7005C9A0F> /System/Library/PrivateFrameworks/XPCService.framework/Versions/A/XPCService
    0x7fffbddb7000 -     0x7fffbddb9ffb  com.apple.loginsupport (1.0 - 1) <03B57D6F-C210-32BC-B384-5B0E95660283> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fffbde0e000 -     0x7fffbde29ff7  libCRFSuite.dylib (34) <BACC371B-6153-36B5-BC54-3BCF26FBB221> /usr/lib/libCRFSuite.dylib
    0x7fffbde2a000 -     0x7fffbde35fff  libChineseTokenizer.dylib (21) <09E74E18-ADB2-30D2-A858-13691CB1186C> /usr/lib/libChineseTokenizer.dylib
    0x7fffbdec7000 -     0x7fffbdec8ff3  libDiagnosticMessagesClient.dylib (102) <422911A4-E273-3E88-BFC4-DF6470E48242> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fffbdec9000 -     0x7fffbe0dcfff  libFosl_dynamic.dylib (16.37) <3EA1C7EE-4A6C-3B09-BCA7-81A074B24013> /usr/lib/libFosl_dynamic.dylib
    0x7fffbe0f8000 -     0x7fffbe0fffff  libMatch.1.dylib (27) <5D52A207-E2AF-3E05-8C51-91C1D82FCEE8> /usr/lib/libMatch.1.dylib
    0x7fffbe100000 -     0x7fffbe100fff  libOpenScriptingUtil.dylib (172) <D025E180-BB3B-3FFA-98FC-B6835354D723> /usr/lib/libOpenScriptingUtil.dylib
    0x7fffbe101000 -     0x7fffbe104ff7  libScreenReader.dylib (477.1.5) <88D484EC-7589-324B-890D-799F27DF0FB3> /usr/lib/libScreenReader.dylib
    0x7fffbe105000 -     0x7fffbe106ff3  libSystem.B.dylib (1238) <168B3C56-081B-3998-9A44-681EB4C6828F> /usr/lib/libSystem.B.dylib
    0x7fffbe172000 -     0x7fffbe19dffb  libarchive.2.dylib (41.1.1) <C4F76D18-8484-3779-AE80-14F27E57ABB5> /usr/lib/libarchive.2.dylib
    0x7fffbe19e000 -     0x7fffbe278fe7  libate.dylib (1.12.12) <1371D20C-3A80-37A5-AB94-09C4C4F67B01> /usr/lib/libate.dylib
    0x7fffbe27c000 -     0x7fffbe27cff3  libauto.dylib (187) <5BBF6A00-CC76-389D-84E7-CA88EDADE683> /usr/lib/libauto.dylib
    0x7fffbe27d000 -     0x7fffbe28dff3  libbsm.0.dylib (34) <20084796-B04D-3B35-A003-EA11459557A9> /usr/lib/libbsm.0.dylib
    0x7fffbe28e000 -     0x7fffbe29cff7  libbz2.1.0.dylib (38) <6FD3B63F-0F86-3A25-BD5B-E243F58792C9> /usr/lib/libbz2.1.0.dylib
    0x7fffbe29d000 -     0x7fffbe2f3ff7  libc++.1.dylib (307.4) <BEE86868-F831-384C-919E-2B286ACFE87C> /usr/lib/libc++.1.dylib
    0x7fffbe2f4000 -     0x7fffbe31efff  libc++abi.dylib (307.2) <1CEF8ABB-7E6D-3C2F-8E0A-E7884478DD23> /usr/lib/libc++abi.dylib
    0x7fffbe31f000 -     0x7fffbe32fffb  libcmph.dylib (6) <2B5D405E-2D0B-3320-ABD6-622934C86ABE> /usr/lib/libcmph.dylib
    0x7fffbe330000 -     0x7fffbe345ffb  libcompression.dylib (34) <AEF908E6-C0FE-3884-BD45-FB37A035545D> /usr/lib/libcompression.dylib
    0x7fffbe346000 -     0x7fffbe346ff7  libcoretls.dylib (121.1.1) <F3BAB54C-DA82-37C3-A218-46FEB179D555> /usr/lib/libcoretls.dylib
    0x7fffbe347000 -     0x7fffbe348ffb  libcoretls_cfhelpers.dylib (121.1.1) <D12709F3-BBE3-3CF7-9070-C2A0803F5526> /usr/lib/libcoretls_cfhelpers.dylib
    0x7fffbe684000 -     0x7fffbe6d7ff7  libcups.2.dylib (450) <04CA1F55-4B70-3D65-B4B1-62F6C271A9EF> /usr/lib/libcups.2.dylib
    0x7fffbe728000 -     0x7fffbe72fff3  libdscsym.dylib (145) <0972B577-B427-3A1C-A9E7-325B6B265135> /usr/lib/libdscsym.dylib
    0x7fffbe751000 -     0x7fffbe751fff  libenergytrace.dylib (15) <A1B040A2-7977-3097-9ADF-34FF181EB970> /usr/lib/libenergytrace.dylib
    0x7fffbe761000 -     0x7fffbe766ff3  libheimdal-asn1.dylib (498) <8F3F1AE8-CE4A-355C-82E3-74DA46B5BB02> /usr/lib/libheimdal-asn1.dylib
    0x7fffbe767000 -     0x7fffbe859ff7  libiconv.2.dylib (50) <42125B35-81D7-3FC4-9475-A26DBE10884D> /usr/lib/libiconv.2.dylib
    0x7fffbe85a000 -     0x7fffbea7ffff  libicucore.A.dylib (57131.0.1) <72594943-D25E-3F70-A4AC-8E9F9F442B7E> /usr/lib/libicucore.A.dylib
    0x7fffbea85000 -     0x7fffbea86fff  liblangid.dylib (126) <3F4530C9-8BE1-3AA7-9A82-98694D240866> /usr/lib/liblangid.dylib
    0x7fffbea87000 -     0x7fffbeaa0ffb  liblzma.5.dylib (10) <44BD0279-99DD-36B5-8A6E-C11432E2098D> /usr/lib/liblzma.5.dylib
    0x7fffbeaa1000 -     0x7fffbeab7ff7  libmarisa.dylib (5) <2183D484-032D-3DE5-8984-3A14006E034E> /usr/lib/libmarisa.dylib
    0x7fffbeab8000 -     0x7fffbed61fff  libmecabra.dylib (744) <545EDC2D-22BB-3E8F-BFD3-921447581D9F> /usr/lib/libmecabra.dylib
    0x7fffbed94000 -     0x7fffbee0cffb  libnetwork.dylib (856.1.8) <30FC3C60-CCA9-3E2B-80AA-DE53F5762374> /usr/lib/libnetwork.dylib
    0x7fffbee0d000 -     0x7fffbf1e2127  libobjc.A.dylib (706) <47104A1B-13E8-369F-BC36-27FF465809FD> /usr/lib/libobjc.A.dylib
    0x7fffbf1e5000 -     0x7fffbf1e9fff  libpam.2.dylib (21) <352F8FF6-2248-3594-B357-8D031DEFB06C> /usr/lib/libpam.2.dylib
    0x7fffbf1ea000 -     0x7fffbf21aff7  libpcap.A.dylib (67) <450DB888-2C0C-3085-A5F1-69324DFE902C> /usr/lib/libpcap.A.dylib
    0x7fffbf238000 -     0x7fffbf254ffb  libresolv.9.dylib (64) <A244AE4C-00B0-396C-98FF-97FE4DB3DA30> /usr/lib/libresolv.9.dylib
    0x7fffbf255000 -     0x7fffbf28efff  libsandbox.1.dylib (592.1.3) <0024D751-23D8-35DF-87CF-72E489DA2F9F> /usr/lib/libsandbox.1.dylib
    0x7fffbf2a2000 -     0x7fffbf2a3ff3  libspindump.dylib (228) <F80FAB75-D656-3FDA-8753-D3D6771B17E6> /usr/lib/libspindump.dylib
    0x7fffbf2a4000 -     0x7fffbf3e5ffb  libsqlite3.dylib (252) <A531C105-64D7-37C0-B999-9320047B71C5> /usr/lib/libsqlite3.dylib
    0x7fffbf441000 -     0x7fffbf491fff  libstdc++.6.dylib (104.1) <91F66BFD-F927-301F-B8F3-578A5CEA78F4> /usr/lib/libstdc++.6.dylib
    0x7fffbf4d6000 -     0x7fffbf4e3fff  libxar.1.dylib (354) <AAFCF321-8100-3622-880B-9661DCA35D69> /usr/lib/libxar.1.dylib
    0x7fffbf4e7000 -     0x7fffbf5d6ffb  libxml2.2.dylib (30.11) <26676155-64CE-323F-B73C-AD77AF5982E8> /usr/lib/libxml2.2.dylib
    0x7fffbf5d7000 -     0x7fffbf600fff  libxslt.1.dylib (15.8) <FFF5DD45-F544-34B2-BE3C-DB877DC60081> /usr/lib/libxslt.1.dylib
    0x7fffbf601000 -     0x7fffbf612ff3  libz.1.dylib (67) <46E3FFA2-4328-327A-8D34-A03E20BFFB8E> /usr/lib/libz.1.dylib
    0x7fffbf621000 -     0x7fffbf625ff7  libcache.dylib (79) <84E55656-FDA9-3B29-9E4F-BE31B2C0AA3C> /usr/lib/system/libcache.dylib
    0x7fffbf626000 -     0x7fffbf630fff  libcommonCrypto.dylib (60092.1.2) <79F738D8-0AD7-3DEA-AF80-E0F8B90B74E3> /usr/lib/system/libcommonCrypto.dylib
    0x7fffbf631000 -     0x7fffbf638fff  libcompiler_rt.dylib (62) <486BDE52-81B4-3446-BD72-23977CAE556F> /usr/lib/system/libcompiler_rt.dylib
    0x7fffbf639000 -     0x7fffbf641fff  libcopyfile.dylib (138) <0DA49B77-56EC-362D-98FF-FA78CFD986D6> /usr/lib/system/libcopyfile.dylib
    0x7fffbf642000 -     0x7fffbf6c4ff3  libcorecrypto.dylib (442.1.3) <1CA8B679-810E-3C04-945A-4AC19372CDC7> /usr/lib/system/libcorecrypto.dylib
    0x7fffbf6c5000 -     0x7fffbf6f7fff  libdispatch.dylib (703.1.4) <12B1D95B-283D-325D-85AB-29A2FFD36987> /usr/lib/system/libdispatch.dylib
    0x7fffbf6f8000 -     0x7fffbf6fdff3  libdyld.dylib (421.1) <CDFBDC9C-418C-369D-B433-F64B0630E640> /usr/lib/system/libdyld.dylib
    0x7fffbf6fe000 -     0x7fffbf6feffb  libkeymgr.dylib (28) <09CD7CA6-46D2-3A9F-B9F1-7C4CA5CA0D68> /usr/lib/system/libkeymgr.dylib
    0x7fffbf6ff000 -     0x7fffbf70bffb  libkxld.dylib (3789.1.32) <48BDBE7F-AAE6-3050-9017-6959051CF16A> /usr/lib/system/libkxld.dylib
    0x7fffbf70c000 -     0x7fffbf70cfff  liblaunch.dylib (972.1.5) <DC31FDEA-FD81-335E-BAA8-5A7395D20772> /usr/lib/system/liblaunch.dylib
    0x7fffbf70d000 -     0x7fffbf712fff  libmacho.dylib (894) <1EAE5ADD-490C-3B1F-9F97-447BA8E0E90F> /usr/lib/system/libmacho.dylib
    0x7fffbf713000 -     0x7fffbf715ff3  libquarantine.dylib (85) <78EF62D8-C890-3FC0-937A-C2FD8CEF8992> /usr/lib/system/libquarantine.dylib
    0x7fffbf716000 -     0x7fffbf717ffb  libremovefile.dylib (45) <C4FC07FF-ED86-382E-B06F-33C34718080C> /usr/lib/system/libremovefile.dylib
    0x7fffbf718000 -     0x7fffbf730ff7  libsystem_asl.dylib (349.1.1) <F0987490-8427-367F-B302-A05A7D61FEBF> /usr/lib/system/libsystem_asl.dylib
    0x7fffbf731000 -     0x7fffbf731ff7  libsystem_blocks.dylib (67) <B8C3701D-5A91-3D35-999D-2DC8D5393525> /usr/lib/system/libsystem_blocks.dylib
    0x7fffbf732000 -     0x7fffbf7bffe7  libsystem_c.dylib (1158.1.2) <5F260836-48E4-3F57-8553-62D2DA228A1F> /usr/lib/system/libsystem_c.dylib
    0x7fffbf7c0000 -     0x7fffbf7c3ffb  libsystem_configuration.dylib (888.1.2) <67BB9D8B-2430-38AD-81A7-F0EC924B2590> /usr/lib/system/libsystem_configuration.dylib
    0x7fffbf7c4000 -     0x7fffbf7c7fff  libsystem_coreservices.dylib (41.1) <11F22E6C-0DCB-3699-A4F0-C99E301E56E9> /usr/lib/system/libsystem_coreservices.dylib
    0x7fffbf7c8000 -     0x7fffbf7e0ffb  libsystem_coretls.dylib (121.1.1) <8F7E9B12-400D-3276-A9C5-4546B0258554> /usr/lib/system/libsystem_coretls.dylib
    0x7fffbf7e1000 -     0x7fffbf7e7fff  libsystem_dnssd.dylib (765.1.2) <C5FF2025-C60B-39C6-B205-6BF1BC51D1B3> /usr/lib/system/libsystem_dnssd.dylib
    0x7fffbf7e8000 -     0x7fffbf811fff  libsystem_info.dylib (503) <C686B834-5E7D-382C-AF6E-44AB78EE83E2> /usr/lib/system/libsystem_info.dylib
    0x7fffbf812000 -     0x7fffbf834ff7  libsystem_kernel.dylib (3789.1.32) <5C68A0D7-C3C9-3E52-B983-EDE9A28AB6FC> /usr/lib/system/libsystem_kernel.dylib
    0x7fffbf835000 -     0x7fffbf87cfe7  libsystem_m.dylib (3121.4) <E3370D16-EBAA-3C7F-AC56-2D6EAD7DB0A4> /usr/lib/system/libsystem_m.dylib
    0x7fffbf87d000 -     0x7fffbf89bff7  libsystem_malloc.dylib (116) <3DD17B88-B7A4-38B9-9E95-AB88E1C3B647> /usr/lib/system/libsystem_malloc.dylib
    0x7fffbf89c000 -     0x7fffbf8f2fff  libsystem_network.dylib (856.1.8) <A8973360-956A-33BF-9971-14D59C84E0D1> /usr/lib/system/libsystem_network.dylib
    0x7fffbf8f3000 -     0x7fffbf8fcff3  libsystem_networkextension.dylib (563.1.11) <1C551832-9360-36DD-A7BA-52B55A171720> /usr/lib/system/libsystem_networkextension.dylib
    0x7fffbf8fd000 -     0x7fffbf906ffb  libsystem_notify.dylib (165) <AF77D471-6B13-36BA-B144-7E7DDB9DBA9F> /usr/lib/system/libsystem_notify.dylib
    0x7fffbf907000 -     0x7fffbf90ffe7  libsystem_platform.dylib (126.1.2) <884DDF42-3CAE-334A-82CE-965617130FB1> /usr/lib/system/libsystem_platform.dylib
    0x7fffbf910000 -     0x7fffbf91afff  libsystem_pthread.dylib (218.1.3) <050AE77B-4F4B-334A-A5BA-CF0D10AF5304> /usr/lib/system/libsystem_pthread.dylib
    0x7fffbf91b000 -     0x7fffbf91efff  libsystem_sandbox.dylib (592.1.3) <90FEF628-316D-3F84-9EF4-F7F510A4FBBB> /usr/lib/system/libsystem_sandbox.dylib
    0x7fffbf91f000 -     0x7fffbf920fff  libsystem_secinit.dylib (24) <A54B8FEF-E792-3C54-8E0B-E80A376662F2> /usr/lib/system/libsystem_secinit.dylib
    0x7fffbf921000 -     0x7fffbf928fff  libsystem_symptoms.dylib (532.1.1) <B26F656E-94F9-3834-9B03-51C4FF11D1BF> /usr/lib/system/libsystem_symptoms.dylib
    0x7fffbf929000 -     0x7fffbf949ff7  libsystem_trace.dylib (518.1.16) <C3CDF7BC-CA3D-34F5-ADF8-46AAAB0B47F8> /usr/lib/system/libsystem_trace.dylib
    0x7fffbf94a000 -     0x7fffbf94fffb  libunwind.dylib (35.3) <9F7C2AD8-A9A7-3DE4-828D-B0F0F166AAA0> /usr/lib/system/libunwind.dylib
    0x7fffbf950000 -     0x7fffbf979ff7  libxpc.dylib (972.1.5) <2A901937-48E1-3BF2-83F1-2431156D82B7> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 2
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 1407
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=336.4M resident=0K(0%) swapped_out_or_unallocated=336.4M(100%)
Writable regions: Total=60.9M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=60.9M(100%)

                                VIRTUAL   REGION
REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Activity Tracing                   256K        2
CoreUI image file                  184K        4
Dispatch continuations            8192K        2
Kernel Alloc Once                    8K        2
MALLOC                            42.3M       15
MALLOC guard page                   32K        6
STACK GUARD                       56.0M        3
Stack                             8712K        4
VM_ALLOCATE                          4K        2
__DATA                            25.9M      231
__IMAGE                            528K        2
__LINKEDIT                       120.3M       13
__TEXT                           216.1M      234
__UNICODE                          556K        2
mapped file                       45.0M        9
shared memory                      340K        9
===========                     =======  =======
TOTAL                            523.9M      524

Description
– When I load a larger Base64 and JavaScript, Atom doesn't respond and crash.
– When I copy the codes of a larger Base64 and JavaScript, Atom doesn't respond and crash.
Steps to Reproduce

Open Atom
Open a project
Open a larger file
You'll load it, but it won't load.
It crashes and asks me to close or to keep waiting.

Expected behavior: [What you expected to happen]
Loading a larger file.
Actual behavior: [What actually happened]
It crashed and didn't respond.
Versions
You can get this information from executing atom --version and apm --version at the command line. Also, please include the OS and what version of the OS you're running.
The atom -- version details:
Atom    : 1.10.2
Electron: 0.37.8
Chrome  : 49.0.2623.75
Node    : 5.10.0

The app --verison details:
apm  1.12.5
npm  3.10.5
node 4.4.5
python 2.7.10
git 2.8.4

Same problem with a large JSON file (2800 lines). As soon as I click on the file in the tree, or if the file was the last one open when I last closed Atom, Atom hangs. Sometimes it recovers. Sometimes I have to restart it.
Atom    : 1.11.1
Electron: 0.37.8
Chrome  : 49.0.2623.75
Node    : 5.10.0

@Undistraction I don't consider 2800 lines to be many. How big is the file? Are the lines very long?

@Ben3eeE Not long at all. File is an array of objects like this one:
{
    "name": "Aquatic warbler",
    "latinName": "Acrocephalus paludicola",
    "imageUrl": "https://www.example.com/example.jpg?width=800&crop=(0,188,900,694)",
    "imagePath": "./data/saved_images/jpg/example.jpg",
    "analysis": [
      {
        "ratio": 0.208655332302937,
        "cmyk": [
          "0",
          "10",
          "31",
          "28"
        ]
      },
      {
        "ratio": 0.198454404945904,
        "cmyk": [
          "0",
          "4",
          "14",
          "48"
        ]
      },
      {
        "ratio": 0.182586295723854,
        "cmyk": [
          "0",
          "2",
          "12",
          "30"
        ]
      },
      {
        "ratio": 0.165172591447707,
        "cmyk": [
          "0",
          "7",
          "28",
          "12"
        ]
      },
      {
        "ratio": 0.133333333333333,
        "cmyk": [
          "0",
          "3",
          "8",
          "67"
        ]
      },
      {
        "ratio": 0.111798042246265,
        "cmyk": [
          "0",
          "0",
          "2",
          "7"
        ]
      }
    ]
  },

@Undistraction I suggest you check if you can reproduce this issue in safe mode atom --safe. If you can reproduce it in safe mode file a new issue here and completely fill out the provided issue template. It would be great if you could also upload a copy of the file. If you don't want to upload it public you can send it in an email to atom@github.com with a link to the issue.
If you are unable to reproduce it in safe mode that indicates a problem with one of your installed community packages. In that case you can try disabling packages until the problem disappears and file an issue on that repository.
This issue is for files that are very large (several megabytes) or have many lines (>100000) and your file sounds like none of those.

Laravel app.js file crashing Atom. This is a large .js file... I tried safe mode, but got the same result. File opens fine in other text editors. This is the output from the terminal after using
atom --safe:
/usr/bin/atom: line 130: 23586 Segmentation fault      (core dumped) nohup "$ATOM_PATH" --executed-from="$(pwd)" --pid=$$ "$@" > "$ATOM_HOME/nohup.out" 2>&1
Failed to get crash dump id.
Report Id:
atom --v:
Atom    : 1.14.2
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0
I'm running Ubuntu 16.04 LTS

Laravel app.js file crashing Atom. This is a large .js file.

Is this a minified file @superjoefly?  If so, I think this is a duplicate of https://github.com/atom/atom/issues/979.

@rsese  Yes...it's minified. I see the issue has been around for a while. It seems that it may be fixed in Atom 1.15.0-beta3. I guess I'll give it a try :-) Thank you for the reference :-)

I'm on 1.15.0-beta3 and I still can't open a 35MB json file :'(

I can confirm that I was able to open the Laravel app.js file in Atom 1.15.0-beta3 with no problem. Thank you Team Atom! :-)

Hey people! Larger files don't work on Atom, both stable and beta and can't be syntax-highlighted. Only smaller and separated files work on Atom.
Firstly work with smaller and separated files on Atom, and when you want to unify all small and separated files into one and to load larger files, with syntax highlighting, use Sublime Text.

I build economic models and the listing files that GAMS produces can be quite large >25MB. It would be convenient to open these in Atom, since I do some GAMS development in Atom (and the text editor in GAMS is rather basic).

I am getting hangs on a file with 5000 lines, problem still persisting in newest beta.
Starting with --safe does absolutely nothing.
I dont care if I dont get syntax hilight etc. The problem is that if you have opened that file once, re-opening atom in that folder will keep your atom editor locked forever.
Solution is to kill all atom data and reinstall.

Actually, in newest beta, deleting the file kills the deadlock.. so there's that!

@olivermt Are you on Windows with spell-check enabled? We have an open issue for spell-check causing performance issues on Windows https://github.com/atom/spell-check/issues/190

@Ben3eeE indeed that test locks up my editor!
Shouldnt atom --safe have disabled that though?

@olivermt  atom --safe only disables community packages. spell-check is a core package that is bundled with Atom.

Wish I knew about that bug before spending 2-3 hours disabling all kinds of weird stuff, reinstalling, tracing here and there blablabla :)
Anyways, that fixes the issue completely for me. Greatly appreciated @Ben3eeE 🥇

Disabling spell-check does not improve at all on JSON load performance. Where in Sublime (2 or 3 doesnt matter) the file opens instantly, atom displays a "Wait for atom" message after loading the file some seconds and then taking another many seconds to finally load the file. 2.7MB one line file.

@pke there are many different reasons for slow performance - there is not a single "catch-all" silver bullet for these types of issues.  In your case, please make sure you are running at least Atom 1.15.0, which contains many performance improvements for large files.

authors: 50Wliu Ben3eeE IgorGee OmgImAlexis Undistraction alexchandel biohazard-zac centic9 chriszrc fewspider gusbemacbe mnquintana nukeop olivermt pke rsese superjoefly wogandavid y6nH


text:
Side-by-side install of atom master?

I currently can have one version of Atom and one version of Atom Beta installed on my machine side-by-side. As someone who works on master most of the time, I have to choose whether the version of Atom (non-beta) tracks against the Release channel or is just a local-built version of Atom.
Could we build support so that I could have Release, Beta and a local-built version of Atom all side-by-side?

Nice idea but not a lot of traction.

source: gharchive/issue

repo: atom/atom

license: MIT

license_type: permissive

license_source: github-api


text:
Remove duplicate to

Requirements for Contributing Documentation

Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
The pull request must only contribute documentation (for example, markdown files or API docs). To contribute other changes, you must use a different template. You can see all templates at https://github.com/atom/.github/tree/master/.github/PULL_REQUEST_TEMPLATE.

Description of the Change
The word to is a duplicate here. (Typical duplicate word error)
The periods/full stops for return types in the documentation seems inconsistent, but I'm ignoring that for now
Release Notes
N/A

btw, clearGrammarOverrideForPath is deprecated but that isn't mentioned in the docs (line 405)...

note 2: More missing docs, getAssignedLanguageId's buffer param is a TextBuffer.

For missing docs, I would encourage you to open a separate issue.

source: gharchive/pull-request


text:
Recycle DOM nodes

After meeting with the Chrome team, we have found out that our GC times were quite severe when many DOM nodes were appended and removed from the tree (e.g. a typical scenario where you can see this in practice is scrolling).
This is a chart that shows how master behaves when scrolling down for a while:

As you can see, the browser is triggering minor garbage collections during the scroll; at some point (which, I think, coincides with some Chrome threshold), a full GC is triggered and it takes quite a long time:

With this PR we are introducing a DOM elements pool, which efficiently allocates and deallocates nodes to minimize GC times. The result is the following:

:chart_with_downwards_trend: :racehorse:
Moreover, we were able to ditch all the code that dealt with strings that contained null bytes (e.g. #8660) because now those characters are retained in the actual text nodes.
Some other pair of :eyes: are most welcome, especially to look out for performance regressions (it feels like innerHTML was a bit faster, but I couldn't confirm this).
Thanks!
/cc: @atom/feedback @nathansobo

It appears that the memory usage of the elements pool will never go down. It should reach an upper bound, of course, but I'm still concerned that someone could accidentally reach an edge case and then their editor is :fire: Can you describe what a "worst case scenario" would look like? I'll take a stab at it ...
It appears that this pool will reach an upper bound based on the complexity of the UI on the screen. So some things to watch out for might be?

Large screens? (Able to fit more stuff)
More elements tightly packed? (Minimized JavaScript perhaps?)
Lots of tabs open? (Or do non-visible elements get freed?)
Lots of panes? (Same as above)

Moreover, we were able to ditch all the code that dealt with strings that contained null bytes.

:heart: Awesome.
Some minor style suggestions:

I would call it DOMElementPool instead of DomElementsPool. We've been doing initialisms like DOM as uppercase in our code lately, and I think that singular noun seems to a more common convention for other pool-type objects, (e.g. "connection pool", "object pool").
Is DomElementsPool::free meant to be called from the outside? If not, I would probably inline at its one call-site in ::freeElementAndDescendants, to make it as clear as possible that you should always use the latter method.

Love the way you structured this with the elements pool. I'm inclined to accept a tiny slowdown of line construction to avoid the big pauses. I'm going to build this and try it out, but in general I'm more worried about janky performance than slightly slower performance. But if you have ideas about how we can have the best of both worlds that would be good too.

It appears that the memory usage of the elements pool will never go down. It should reach an upper bound, of course, but I'm still concerned that someone could accidentally reach an edge case and then their editor is  Can you describe what a "worst case scenario" would look like? I'll take a stab at it ...

@lee-dohm: that's a really good concern but I think this won't be worse than what we have currently. Let me explain why:

Large screens. Memory usage will reach an upper bound pretty quickly and, since the lines on screen will always be quite the same amount, we shouldn't waste memory. The worst case scenario here is when we haven't got much content on screen and, as a result, the pool is almost full. In practice, this could happen only at the end of a file when "scroll past end" is true.
More elements tightly packed. I think the same reasoning of 1) applies here. The upper bound of the pool is the number of lines that can fit on a screen (which, roughly, is also our lower bound, except in the worst case scenario mentioned above).
Lots of tabs/panes open. Currently, when we have more than one tab open, the ones that are hidden still retain all the nodes inside them and, as a result, we shouldn't see any difference in memory usage.

What do you think? Am I missing something there? On the other hand, I realized we need to make sure that the pool gets disposed properly so that its nodes can be garbage collected when the editor is destroyed.

Some minor style suggestions:
I would call it DOMElementPool instead of DomElementsPool. We've been doing initialisms like DOM as uppercase in our code lately, and I think that singular noun seems to a more common convention for other pool-type objects, (e.g. "connection pool", "object pool").
Is DomElementsPool::free meant to be called from the outside? If not, I would probably inline at its one call-site in ::freeElementAndDescendants, to make it as clear as possible that you should always use the latter method.

Love the way you structured this with the elements pool. I'm inclined to accept a tiny slowdown of line construction to avoid the big pauses. I'm going to build this and try it out, but in general I'm more worried about janky performance than slightly slower performance. But if you have ideas about how we can have the best of both worlds that would be good too.

Thanks for the suggestions guys! :sparkles: Eventually I went with DOMElementPool, but kept ::free as a private method (i.e. not testing it in the specs) 'cause it felt a bit cleaner code-wise.
Overall I feel pretty good about this, exception made for the lines construction routines which seems a bit slower. I'd like to hear your feedback as well after you try this out; in the meantime, I am going to research how we can minimize those times when/if we resort to a background thread.

What do you think? Am I missing something there?

I see now that you're releasing the freed elements in the build method, so that takes care of my concern :grinning:

Hi there, nice work! Object pools have always been an efficient way to fix performances problem and have proven to be very effective (I'm using it for both pigments and in my csv editor package and it achieved great results).
I think, in the case of text editor tiles and lines, I can imagine a much more worst scenario even if it won't happen on each run:
When changing the font size from the settings view, if you don't type the size quickly enough you can end with lines with a height of 1px for a short moment. In that case your pool will reach an amount of elements completely meaningless after you revert to a proper font size. It'll also occurs if you unintentionally change the font size with the other available means, but I believe it will have less impact as the change should be less radical than when going from 14 to 1 and then to 12 for instance.
I frequently faced these kind of sudden burst of instances back when I was working in the flash game industry. You can have special events in a game that trigger a massive amount of particles (and we all love that :grin:). But to avoid having a too huge memory footprint after that I was frequently capping the freed instances collection based on data collected during the testing.

Thank you for sharing this super useful insight! That's an edge case I hadn't think of and which we should definitely address.
I think we have a couple of ways in which this could be hypothetically fixed:

Clearing out DOMElementPool when fontSize or lineHeight change. This is the most straightforward in my opinion and exploits the assumption that those parameters won't change that frequently under typical usage.
Setting an absolute upper bound, as @lee-dohm proposed. This needs to be configured, though, and there's the risk of choosing a value that's not quite right.
Setting a relative upper bound. The idea here could be to work with ratios, configuring the pool to rebalance automatically once the ratio reaches a certain value (i.e. ratio here could be defined as freedElements / builtElements for a given series of moments t0, t1, t2...). Although this is probably the best solution possible, I'd prefer to keep the pool code simple and straight to the point unless some more complex interaction becomes mandatory.

I went ahead and implemented 1) in daf4316. @abe33: your experience with games would be super helpful here, so please let me know if you think there could be anything wrong with this solution. Thanks again! :+1:

@as-cii :heart: :green_heart: :yellow_heart:

@as-cii Solution 1 seems fine too.
Solution 2 woud require some metrics to be really accurate and solution 3 seems more complex to me without having good metrics to analyze.
For instance if I remove all the code in a file we'll end with a ratio used/freed of 1/N where N is the number of lines used before the deletion, but we should not rebalance anything because this is kinda the expected result in this case, but at the same time, the same ratio could be obtained in the scenario I described above but in that case a rebalance would be required.

Thanks everyone! :heart:

If the pool re-balance become an issue I'll throw one idea:
At each generation, free a small percent of the pool.
That way you'll avoid steady state error without having to maintain complicated statistic about ideal condition.
Suppose you free 1% of the pool per generation. Then suppose some event occurs that drastically reduce the number of node required (say snap to half of screen). After about 300 generations you'll come to about 5% of the new operating condition whatever that new condition is (0.99^300≈0.05) .
If you sync those generation with screen refresh (say about 60 per second), it means you'll adapt in about 5 seconds to the new condition. Which is relatively short in term of wasted memory for the user, but at the same time an eternity if you compare to the 30ms timescale of the garbage collection screenshot.

authors: abe33 as-cii benogle jeancroy lee-dohm maxbrunsfeld nathansobo


text:
[WIP, experimental] Async Git Repository class

This is an experimental spike of an alternate GitRepository class that uses nodegit rather than git-utils. We would love to speed up the responsiveness of various aspects of Atom (tree-view, etc) by doing more Git operations asynchronously, and it would also be nice to get out of the business of maintaining our own libgit2 wrapper.
Here are a few notes about the reasoning behind some decisions here:

It follows the existing GitRepository API closely, changing everything sync to Promise-based async.

The assumption is that having a close mapping between the sync and aysnc APIs will make it less painful to refactor client packages.
I'm not 100% sure we should keep this design, so it's a tradeoff between design quality and incurred labor. Ideally we'll keep this private and experimental all the way until Atom 2.0 so that we can change it as we need to.

The class is written in ES6, because Coffeescript, while lovely, is the past, and the community seems to have consensus on transpilers like babel.

This includes an .eslintrc, because I've found it extremely useful.
The spec is still in coffee because I thought it might be easier to just modify it as I go to make sure I had the same coverage on both classes, though at the moment I wish I'd run it through a coffee -> js converter first.

I haven't done a lot of ES6 or constructed a Promise-based API for anything serious before, so I'm sure to misuse some APIs.
We'll need to keep the sync GitRepository class around for backwards compat, so I haven't decided quite how to integrate this with the current provider system.

Perhaps we add a private method on the sync repo like GitRepository.async that returns the Promise for an async repo, so that internal callers can use async without changing anything in the GitRepositoryProvider?

Documentation is sparse because I wasn't sure this was a good path to follow until today. I'll flesh it out more as I go.

cc @atom/core @orderedlist

What's the plan for transitioning to this API? I was thinking our existing synchronous GitRepository could always have an async property that points to this new version. We can then encourage users of today's APIs to use the async version like this:
let repository = someMethodReturningARepository().async

When we hit Atom 2.0 and transition to the repository always being async, we can retain the async property and just point it to self, such that repository.async === repository returns true.
However, I'm not sure how this all meshes with your idea of keeping this API private for a while. In my mind, we should start transitioning the community to any async APIs we feel confident about. We might not want to make every method on the class public, but I'd like to deprecate existing synchronous functionality as soon as we can.

I was thinking our existing synchronous GitRepository could have an async property that points to this new version.

Yep, I agree with this, it's suggested in the bullet points above.

However, I'm not sure how this all meshes with your idea of keeping this API private for a while. In my mind, we should start transitioning the community to any async APIs we feel confident about.

This is not necessarily a conflict with how I feel, I'm just not expecting we'll feel confident about the APIs for a while.

:zap: Thanks for moving us in the right direction on this.

it's suggested in the bullet points above.

Sorry, I didn't comprehend it initially for some reason. Of course async will have to be a promise, and when we transition all our repository-returning APIs to be asynchronous, we'll have to have an async property on the returned promise that references the original promise.

Oh hey, this will be excellent for packages that integrate with git. :+1: :grin:

:heart: ES6 instead of :coffee:script!

Thought: it seems like a good place to start using this in prod & packages is to proxy all the did-change-status events from the sync implementation to the async implementation. At this moment I'm just writing tests that assert the events fire correctly in async-land at all and calling through from sync to async in a few methods (e.g. getPathStatus(path)) just so the side-effects happen, but ultimately we could remove anything solely concerned with generating events out of the sync implementation entirely and just re-emit the ones generated by the async implementation.

Thanks for the feedback @steelbrain!

You guys really hate placing semicolons don't you? :D

By not adding semi colons, are you adding overhead to the JIT?

On Oct 23, 2015, at 12:04 PM, Alex Cruz notifications@github.com wrote:
You guys really hate placing semicolons don't you? :D
—
Reply to this email directly or view it on GitHub https://github.com/atom/atom/pull/9213#issuecomment-150619013.

@SeanJM I don't know why github doesn't use them in their code, is this because they have most of their code in Ruby?

https://www.quora.com/Are-there-performance-differences-between-using-semi-colons-and-not-using-semi-colons-in-JavaScript https://www.quora.com/Are-there-performance-differences-between-using-semi-colons-and-not-using-semi-colons-in-JavaScript
According to this the answer is no.

On Oct 23, 2015, at 1:11 PM, Alex Cruz notifications@github.com wrote:
@SeanJM https://github.com/SeanJM I don't know why github doesn't use them in their code, is this because they have most of their code in Ruby?
—
Reply to this email directly or view it on GitHub https://github.com/atom/atom/pull/9213#issuecomment-150636085.

Hm, I only have 2 (seemingly unrelated) failures on my machine, but there are a bunch of :red_circle: on travis. In any case this is starting to come together nicely.

but there are a bunch of :red_circle: on travis

You may want to run tests against the current released version rather than master locally just in case that's a factor.

Whoops! @nathansobo i meant to post that comment on the tree-view PR. Tabs are hard.

Over in #9469 as of this moment I have just the buffer callback stuff implemented (i.e. the specs that are weirdly flaky on this branch) and consistently green. I'm not sure what the essential difference is though. One difference is that I implemented ::relativize in that PR rather than just proxying to the git-utils version, but I'm not sure how that's relevant. I also implemented the specs slightly differently, with some gentle use of async/await. In any case, tomorrow I'll port some of the differences over to this branch and see if it makes things green here, else I'll port things from here to there one section of specs at a time and see if any one area starts to make async-land flaky.

So I think this branch is in a pretty good spot now.

Ported more tests to JS.
Moved from Jasmine waiting to async/await as much as I know how.
Fixed a race between file writing/git reading.

The tests seem to consistently pass locally now. I'd be really curious to know how they behave for you now too :pray:
My plan for Monday was to:

[ ] Continue porting tests to JS.
[ ] Make terribleWait and terribleSleep less terrible.
[ ] See about getting CI building again so we can have some consistency to testing.

If you wanted, we could divide and conquer that.

Fixed a race between file writing/git reading.

😻

If you wanted, we could divide and conquer that.

Sure thing, let me attack this CI thing first.

The last build failed on a bunch of license checks, at least a couple related to eslint & standard added as devDependencies. One could argue that those libs are only used to develop, not in the distribution, so it's fine that their licenses aren't permissive. though I'm not 100% sure that holds water. For now I'll just take them out of the package.json (but leave in the config for standard) and see if that clears up this check license task.

So the tests are in a pretty good spot now, I think. There's still a potential race condition but I haven't seen in practice. I'm thinking over how to best fix it.
But the more pressing problem is that CI is timing out.
master currently builds in ~1200s, where this is timing out at 1800s. So somehow this added ~10 minutes to the build.
I'm not entirely sure where the time's being spent. Anecdotally we seem to spend a lot of time in the Installing apm... phase. We're using node-pre-gyp to download the nodegit binary (or at least, that happens locally; unclear how to verify that from CI output).
@atom/feedback Anyone have ideas? If not I'll probably try to break some of the steps down and time them.

nodegit takes forever to build in apm because there aren't any binaries. This is probably something we should fix in nodegit.

Also, atom.io can have high latency sometimes, and we hit it many times to install core packages. I do plan to do a performance pass there at some point in the future, but in any case it would be so cool if we could just bundle / cache those dependencies rather than going over the network.

nodegit takes forever to build in apm because there aren't any binaries. This is probably something we should fix in nodegit.

nodegit uses node-pre-gyp to provide binaries, but it looks like it special-cases Electron apps to always build from source: https://github.com/nodegit/nodegit/blob/b259b0587c6e44e3939e49055b90845fbfce9221/lifecycleScripts/install.js#L27 Presumably because Electron wasn't supported until fairly recently? https://github.com/mapbox/node-pre-gyp/pull/175

but in any case it would be so cool if we could just bundle / cache those dependencies rather than going over the network

I'd love to do some sort of binary caching but I'd really love for it to not block this.

@joshaber I brought up the Installing apm... thing in chat the other day because it takes forever on my laptop as well though it "should be fast", worth looking into. Though it would be a shame to yak shave too much. The nodegit node-gyp path seems like the lowest-hanging fruit.

Installing nodegit actually has to compile libgit2 as well, which takes some time. Realistically, an apm binary for nodegit would make this wayyyyy faster.

Yeah I'm looking into adding Electron binaries to nodegit.

@orderedlist is right with building libgit2 but it's even worse than that. NodeGit has to build libgit2/libssh2/openssl which is as horrible as you think it is. Luckily we don't have a C++11 requirement anymore but it's still super slow.
Anyways, so nodegit/nodegit#783 is in and ready to go so really the next step is to have the CI build/publish binaries for linux/darwin/win32 during a release. That way everything is just automated and ready to go. The only thing that would break is if a new version of electron is released there's no way for nodegit to pick up on that and we won't be able to grab a binary for the latest.
The only way around that (that I can think of right now) is just having a box that hooks into releases of electron and automates building/publishing for nodegit.
This might not be too much of a problem when Electron gets to v1 but still, it's going to be a pain to always go back and build/publish this guy when Electron gets a version bump.

:metal: Tests are passing, just need to get build times down so it doesn't time out :metal:

Alright, I believe this is ready for review :pray: @atom/feedback
There are two caveats:

The Windows builds are still timing out because we're having issues getting Windows nodegit binaries. Still a work in progress. I won't merge this until that's taken care of.
Submodule support is incomplete. I'm working on it, but I think this can land without it, so long as everyone's aware.

My current plan is:

Add submodule support once a new nodegit version is out.
Convert tree-view, status-bar, and git-diff to async.

Alright, I believe this is ready for review :pray: /cc @atom/feedback

Gave it a review pass, left some comments. I know a lot of this code was ported over from the original sync version so I apologize if any of the comments pertain to things that were legacy and are just showing up in the diff because of the movement.

:heart: This looks great.

@kevinsawicki Thanks! :sparkling_heart: I think I :hammer:'d them all.
Any other feedback is welcome. Otherwise this is just waiting on Windows nodegit binaries.

Any other feedback is welcome.

Took another pass, left a few minor comments. This is looking really good though :+1:

:zap: :eyes:

Thanks @YuriSolovyov!

Look at that lovely green checkmark :heart_eyes:

I've verified Mac and Windows binaries are working. Linux will have to wait until after the new year.

Coincidentally, 2016 is the year of Linux on the desktop, so that works out great.

:penguin: :fire:

Even though it's not yet 2016, I verified that the Linux build is working :metal: :penguin:

Hoping to merge this tomorrow :pray:

There's reportedly a problem with the Linux nodegit binaries.
From @johnhaley81:

It seems to only affect LTS linux...
It's very strange. Like it's executing a CPU instruction that's not available to older versions of ubuntu.

So I'm going to hold off on merging this until that's resolved.

I'll keep you posted as I find out more.

CPU instructions are not bound to software, but to hardware. If Linux binaries are not working on LTS Ubuntu (as there is no such thing as LTS Linux) it means you're using unavailable libraries (most probably). ldd should be enough to check that.

FWIW, it worked fine for me in testing on Ubuntu 64-bit 14.0.4.3

The LTS Linux was a typo. I meant Ubuntu. The issue was when requiring the NodeGit library it would throw a SIGILL. It throws this when it's initializing OpenSSL for the library but not at a specific line of code. It dies when it returns from the first method in the call stack after init is called.
This happens with the prebuilt binary off of Travis. I'm attempting to configure a VM to allow @joshaber to have a consistent repo since it seems to be a heisenbug as well.

SIGILL errors are expected in OpenSSL. Check https://www.openssl.org/docs/faq.html#PROG17

That says under debugger situations which we aren't in. We're in a full production build without an attached debugger. Is that expected under that scenario as well?

Ahh I re-read it and it's saying that during it's query for a CPU's capabilities it could get a SIGILL. Running the code though it was happening during a request to dev/random and it did successfully get a result from that. It dies when it pops the function from the call stack.

@alexandernst here's the ldd -v output for each binary. The shared libs looks the same to me. Also, are those hex values the address in the binary where the lib is loaded?
https://gist.github.com/johnhaley81/617f36595b35513cc2a4

@johnhaley81 Can we get the backtrace too?

@alexandernst https://gist.github.com/johnhaley81/abbc6dd801eca780ae7f

@johnhaley81 It looks either like nodegit was compiled for the wrong arch (can you show me how is it compiled?) or an OpenSSL bug (less likely, but possible).

@alexandernst this is the prebuilt binary compilation log: https://travis-ci.org/nodegit/electron-npg-automator/jobs/97494428

Also so you know, I have a "magic" Ubuntu box that's configured the same way that works. Clearly not everything is the same but it's a clean install, no updates, only those packages are install, same env-variables and same compiler and compiler version. And that works. I can give you any outputs from that machine that you like.

@johnhaley81 Just to make sure I understand the situation. The bug you're getting exist only in a VM that you use to test? Or can you repro the bug easily in any LTS Ubuntu?

@alexandernst I've had reports of users experiencing this across multiple versions of Ubuntu. I have only been able to repro this consistently on this on 2 VMs and only when running Ubuntu. Mint and CentOS work.

Also my local install of Ubuntu works fine with either build.

@alexandernst @joshaber mentioned that the disassmble of the running app might help

(gdb) x/i $pc
=> 0x7fc83ef3851c <lh_new+332>:    vxorps %xmm0,%xmm0,%xmm0

This seems to be the instruction it's SIGILL'ing on.

@johnhaley81 @joshaber http://www.felixcloutier.com/x86/XORPS.html
Do the users's CPUs that are reporting the problem support AVX?
Also, I'm yet to see how nodegit is exactly compiled (the link @johnhaley81 posted doesn't have that info). Are you compiling with -march=native or something?

@alexandernst that travis box loads the repo from github and then we have the GYP file loaded https://github.com/nodegit/nodegit/blob/master/vendor/libgit2.gyp which sets the flags. That is how the makefile is generated. We then use node-gyp to compile the module.

@alexandernst as far as AVX support, I'll get back to you on that. Looking into it as much as I can now.

Maybe something weird is going on in the Makefile. Can we get a copy of the generated Makefile?
About the AVX, check if available with cat /proc/cpuinfo| grep avx

Also, the version of clang, if possible.

The definitely are lacking avx. So here's a potential fix: https://github.com/nodegit/electron-npg-automator/commit/d4a8725b7d42011cd39edf938d1927f97500eb04
The use_obsolete_assembly should force OpenSSL to NOT use that but I think that setting it to true might have not set the flag correctly? Trying this out now.

There you go, it's a compiler flag. That's why it was working on your machine (which I guess it does support AVX) and not in the machines of some of your users. Find how to force the compilation process to avoid using unsupported CPU ops.

Compiler flag didn't fix. Turns out it's possibly a bug in OpenSSL. Potential fix: https://github.com/nodegit/nodegit/pull/855

Indeed, turns out it's an OpenSSL bug :)
https://github.com/openssl/openssl/commit/817ddb9fb07e78b451e838a77b2b272b0dd23e5f

Confirmed, that fixes it.

Bumping to NodeGit 0.7.0 should resolve that linux issue and make this PR gtg :)

Hm, I guess I didn't cross-reference this here: https://github.com/atom/atom/pull/10352
^ This is a fix for ::relativize on this branch that still needs a little polish

I'm seeing intermittent failures about file watching, e.g.:
>> GitRepositoryAsync
>>   .checkoutHeadForEditor(editor)
>>     it does not display a dialog when confirmation is disabled
>>       Error: Leaking subscriptions for paths: /private/var/folders/gw/_2jq29095y7b__wtby9dg_5h0000gn/T/atom-working-dir116011-49688-dfmojy/a.txt
>>         at ensureNoPathSubscriptions (/Users/travis/build/atom/atom/spec/spec-helper.coffee:122:15)
>>         at [object Object].<anonymous> (/Users/travis/build/atom/atom/spec/spec-helper.coffee:115:3)
>>         at process._tickCallback (node.js:368:9)
>>   .destroy()
>>     it throws an exception when any method is called after it is called
>>       Error: Leaking subscriptions for paths: /private/var/folders/gw/_2jq29095y7b__wtby9dg_5h0000gn/T/atom-working-dir116011-49688-1pr3ez3/a.txt
>>         at ensureNoPathSubscriptions (/Users/travis/build/atom/atom/spec/spec-helper.coffee:122:15)
>>         at [object Object].<anonymous> (/Users/travis/build/atom/atom/spec/spec-helper.coffee:115:3)
>>
>>

GitRepositoryAsync itself doesn't do any file watching directly. Is this a bug somewhere else? Some cleanup we're not doing? @atom/core

I moved some stuff around which maybe fixed that? I dunno.
I think we're just waiting on #10352, and then :tada: :balloon: :birthday:

Awesome work here :+1:

w00t!

Does this address #2456?

@martindale it would be great if you could download the 1.7.0 beta and find out :).

Subjectively, the problem appears to be worse with 1.7.0 beta.  Atom now completely hangs when launching it inside of a remote mount, and eventually requests direction on whether to close or keep waiting.

Same problem here, Atom 1.6.0 or 1.7.0 beta now hangs up when trying to open a big git repository inside of a remote mount making Atom unusable in this configuration :cry:

Can't use Atom anymore. Probably because of this feature. I mounted a vagrant via SSHFS and Atom freezes when opening a file. Could you release a fix for this, please.

I'm wondering why we switched to using nodegit. I realize that maintaining a wrapper around a git executable is lame but nodegit wraps libgit2 which is glacial in comparison to git. This is completely anecdotal but I've always found it far slower.
Perhaps using something like https://www.npmjs.com/package/simple-git instead?

@mehcode Before nodegit we were already using libgit2, with a sync api wrapper we were maintaining ourselves (https://github.com/atom/git-utils) - so we can't blame any performance regressions on libgit2 here.

Ah. I was under the impression we were just doing shell execution.

authors: 50Wliu SeanJM alexandernst bynite johnhaley81 joshaber kevinsawicki martindale maxbrunsfeld mehcode nathansobo orderedlist peduxe smashwilson thedaniel yannickcr


text:
App: setUserTasks: can't give more than one argument

The task shows fine:
app.setUserTasks([{
  title: 'Hello world',
  description: 'This is shown in a tooltip',
  arguments: '--hello-world',
  program: process.execPath,
  iconPath: process.execPath,
  iconIndex: 0
}]);

Doesn't show:
app.setUserTasks([{
  title: 'Hello world',
  description: 'This is shown in a tooltip',
  arguments: '--hello-world --another',
  program: process.execPath,
  iconPath: process.execPath,
  iconIndex: 0
}]);

Windows 8.1. Electron 0.36.7.

I'm not able to reproduce, can you try calling app.setAppUserModelId to set an application user model ID before calling app.setUserTasks?

Closing until more information is provided.

authors: adam-lynch zcbenz

repo: atom/electron