phpStorm 8 - Problem dużych plików Opcje

[Pyton_000]

Czy też macie taką straszną zamułkę jak odpalacie większe pliki?

Mam problem ze stabilnością i płynnością po odpaleniu np. css (content to: normalize.css w wersjii min + 2200 linijek css normalnego)
Program zaczyna straaaasznie zwalniać. Pliczek nie ma wielkich rozmiarów sam w sobie. Ok 150tyś znaków.

Pracuję na lapku ale na pokładzie jakieś tam i7, 12GB ram (bez SSD).
Mój phpstorm64.vmoptions

Kod

-Xms256m
-Xmx1796m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=225m
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-Dawt.useSystemAAFontSettings=lcd

[by_ikar]

2k linijek to nie jest jakoś specjalnie dużo, ostatnio 160mb plik sql otworzyłem i nie było jakiegoś problemu.. Kwestia tego czy masz laptopa czy pcta, w sensie dysku (5400/7200 rpm) ?

[Pyton_000]

Mam lapka. Dysk hmm... nie pamiętam ile rpm ale jest to sshd.
Generalnie nie marudzę o szybkość otwierania plików, ale o działanie samego programu po otwarciu. Po wczytaniu całego pliku przeglądanie czegokolwiek w samej aplikacji strasznie klatkuje. Nie jest to raczej problem samego odczytu z dysku a raczej wydajności skanowania zawartości pliku. Nie wiem sam.

[by_ikar]

No to tutaj jest twój problem. Mi w pracy na lapku też muli jak indeksuje.. SSHD to nic innego jak zwykły hdd + większe cache. No ale jak ci klatkuje, to obstawiałbym raczej coś innego. IMO developerka na lapku jest męcząca, strasznie, zwłaszcza że w domu mam dość mocnego kompa i różnica w działaniu zarówno phpstorma jak i vagranta jest kosmiczna..

[Pyton_000]

Nie powiem, ale mój lapek ogólnie daje radę. Odpalanie dużych plików w innych programach nie powoduje zagotowania się sprzętu
Wręcz powiedziałbym, że mój sprzęt się strasznie nudzi

[!*!]

Miałem podobny problem w innym programie, wyłącz kolorowanie składni lub zmień bufor odczytywania linijek (nie pamiętam nazwy tej opcji, chodzi o to, aby program odczytywał np. co 10 linijek i je kolorował zamiast wszystkich "na raz").

[Pyton_000]

Haaa... zauważyłem że muli bo normalize.css który jest doklejony do pliku jest w 1 linijce co daje nam baaaaardzo długą linię. Reszta jest do 120 kolumny +/- więc jest ok.
A jak zrobiłem reformat kodu i ukazał mi się ładny i czytelny to zaczęło śmigać

Teraz pytanie, czy jest możliwość zwiększenia buforu dla linii (jej długości czy cos w ten deseń) żeby wyeliminować taki efekt.

[by_ikar]

W sumie, coś w tym jest, jak próbowałem ostatnio jakiś jednoliniowy plik edytować to też nie za bardzo było to edytowalne, w sensie program dziwnie się zachowywał.. Jeżeli ci się chce, zgłoś buga, podejrzewam że poprawią to

[!*!]

Teraz pytanie, czy jest możliwość zwiększenia buforu dla linii (jej długości czy cos w ten deseń) żeby wyeliminować taki efekt.

Nie, bo niby jakby to miało działać? Pokolorujesz pierwsze 20 znaków a reszty już nie? To nie bug, tak ma być.

[Pyton_000]

nie chodzi o pokolorowanie bo to działa dobrze,
Raczej chodzi o to że 1 linia jest (może być?) przechowywana jako jedna referencja do jakiejś tablicy.
I wtedy taka ogromna linia powoduje spadek wydajności bo operacje są wykonane na jednej zmiennej.

Ot takie gdybanie
Pozostaje mi jedynie przeformatować taki kod do normalnej postaci, a potem zrobić minify.

Dla porównania np. Sublime z wieloma pluginami nie dostaje takiej czkawki ale to może być spowodowane że Storm to Java a Sublime to Python().