Re: Výkonové problémy při nahrazování

Mám soubor o velikosti cca 50 MB. V tomto případě jde o dump SQL databáze. Potřebuji v ní udělat náhrady (tato db má specifické řešení pro ukládání českých znaků takže např Č = C~,...) Těch znaků je cca 20 takže není problém použít opakovaně Najdi a nahraď. Jen to u takto velkých souborů dost dlouho trvá. Když mám nahrazovat např á = a| a v souboru jsou desítky tisíc výskytů, trvá na výkonnějším počítači náhrada desítky vteřin až jednotky minut. Když tu samou operaci udělám v hloupém poznámkovém bloku, náhrada proběhne do pár vteřin. Chápu že toto není úplně častá práce, ale sem tam něco podobného potřebuji dělat a tak se ptám - nedala by se v PSPadu udělat nějaká urychlující optimalizace? Při této náhradě vím že se nepotřebuji vracet k původnímu stavu (stejně se po náhradě dozvím že náhrad bylo více jak možných UNDO kroků), nepomohlo by třeba pro urychlení mít možnost vypnout ukládání provedených změn (zaškrtávátko v dialogu Najdi a nahraď)?

Dobrý den, jaká verze PSpadu?
Pro hromadné nahrazování je dobré využít z menu nástroje Uživatelské konvertory.
Ve slozce .\Convertor je příklad ve formě souboru Template.in_, ktery si prejmenujte např. na SQL LOG.ini

Obsah bude třeba:
[Settings]
ForwardName=SQL LOG
ForwardIgnoreCase=0
ConversionStyle=strings

[Strings]
Č|C~
Á|A~
...


Do sekce [strings] si doplnte seznam vyrazu, ktere chcete nahrazovat. Spustenim pak provedete najednou koverzi vsech 20 výrazů.
Pokud si podle Template.in_ doplníte i backward pojmenování, pak to PSPad zvládně nahradit zpět i do češtiny.

ForwardName=SQL LOG - zrus cestinu
BackwardName=SQL LOG - vrat cestinu
ForwardIgnoreCase=0
BackwardIgnoreCase=0

Zkusím se podívat, jak by to šlo optimalizovat. Notepad bude rychlejší, protože neřeší v podstatě nic, co musí řešit PSPad.

Edited 1 time(s). Last edit at 2022-03-25 11:49 by pspad.

Zdravím,
nejsem si jist, jestli je to ještě aktuální, ale mám pocit, že svého času se nahrazování zpracovávalo po jednotlivých nálezech (asi aby se zahrnulo do undo historie ?), možná dokonce s přesouváním kursoru a vybraného textu (to je ale asi s optimalizacemi už jinak (?)).
Podstatnější je to na velkých souborech a hlavně na dlouhých řádcích (nevím jestli se to týká tohoto sql).

Svého času mě překvapilo, že nahrazení jednoduchým javaskriptovým kódem mohlo být výrazně rychlejší než vestavěná funkce, asi hlavně proto, že se vykreslování omezilo (načte se celý text editoru do řetězce, provedou se nahrazení a výsledkem se nahradí zase celý obsah editorového textu).
Bylo by to něco jako u někdejšího postu s řadou nahrazení
forum.pspad.com

Nevím, jak se skriptové rozhraní WSH vyrovná s 50megabajtovými objemy;
navrhovaný uživatelský kontertor je ale určitě pro toto užití vhodnější.

zdravím,
vbr

Proto jsem se ptal na verzi. Starší verze to tak dělaly, snažil jsem se to pak optimalizovat.

Verzi mohu poslat v pondeli (bylo to na pracovnim PC, kam se ted nemohu prihlasit) - ale mela by to byt jedna z poslednich - pred par mesici jsem aktualizoval na jednu z tech padavejsich verzi (nebo ta co vkladala obcas nahodne znaky do souboru) a na vasi radu jsem instaloval nejakou novou verzi, ktera jeste nebyla oficialne vydana. Uzivatelske konvertory vypadaji naprosto uzasne - dodnes jsem na ne kde sve smule v PSPadu nenarazil - v pondeli je zkusim a napisu sem vysledek.
Diky

Tak chci vyzkouset konvertory, ale narazim na problem - v nich se jako oddelovac pouziva znak | - jenze ten ja mam v datech jako soucast nahrazovanych znaku (napr. A| => Á) - je mozne pouzit pro oddeleni jiny znak?

Dival jsem se do napovedy jestli se neda oddelovac definovat a bohuzel neda. Nestálo by za to přidat do konfigurace možnost nastavit si vlastní oddělovací znak?

Zatím to možné není, ale není problém přidat do nastavení zvýrazňovače konfiguraci oddělovacího znaku.
Provedu

V dalsim buildu 5.0.7 bude možné v sekci [Settings] použít proměnnou:
DelimiterChar=|
Roura zůstane jako výchozí i když proměnná nebude existovat kvůli zpětně kompatibilitě. Ale umožní vám nadefinovat si vlastní znak.