Suddenly shiftedit is taking longer than usual doing anything

[frafor]

Be it save a file, old or new, large or small, it is not only taking really long, but it freezes the interface and nothing else can be done.

Trying to go from top to bottom in a file has become a heavy event: it will start moving in bursts, but not in one single jump.

And when typing, it has really become a slow process (PHP or JS file).

[adamjimenez]

Which browser and ShiftEdit version are you on?

[frafor]

Browser: Chrome Versión 68.0.3440.106 (Build oficial) (64 bits) ShiftEdit: Version: 19.0.45 Edition: Basic ...

On Wed, Aug 15, 2018 at 4:16 AM Adam Jimenez notifications@github.com wrote:

Which browser and ShiftEdit version are you on?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/adamjimenez/shiftedit/issues/322#issuecomment-413141165, or mute the thread https://github.com/notifications/unsubscribe-auth/AEgD2ct3Zl-tkkss-ikGesmMLdNmN1Yeks5uQ-b1gaJpZM4V9YKL .

[adamjimenez]

Does the problem persist in the dev version? https://shiftedit.net/update-details

[frafor]

Yes, it persists in the dev version.

Version: 19.0.52 Edition: Basic

My 4201-line php file makes little jumps when I type control-End or control-Home, instead of going directly to the first or last line and only showing the first or last page.

Page-Up and Page-Down are behaving just as jumpy or worse, because they make from 4 to 6 jumps from page to page.

Typing on any file has become a hassle: typing has become a slow motion process, even typing text inside a comment (// o / /).

Of course, this did not use to happen in the past.

(I just moved it back to regular V 9.0.45)

[adamjimenez]

Can you try in an incognito window to rule out browser extensions? Does disabling autocomplete make a difference? Is it a low power computer?

[frafor]

In incognito window, it is just as slow (maybe even slower... can't say)

Control-END control-Home, with or without autocomplete, take a long time.

The computer is rather powerful: 15 GB of RAM, 256 GB Solid state disk drive. Cpu

Watch how the CPU goes up by moving keys (control-home and control-end).

Take a look at how powerful the pC is:

Everything else, except ShiftEdit, flies!!!

See: 4 processors, 8 logical processors:

[adamjimenez]

Does disabling autocomplete make a difference?

[frafor]

Nothing made a difference. Nothing. I am using a local editor and sending files by ftp now. But I do not want to continue like that forever. Also, when I save a file, it takes FOREVER for the control of the program to be available again.

[adamjimenez]

Does it happen in firefox? It could be a preference option or you could try re-creating the site. It's strange as it's the only report of this and there haven't been any changes I can think of that would cause this.

[frafor]

It DOES happen in Firefox and in Edge. I have juste checked, it also happens in Opera, and now I checked skins and themes and editor colors, etc.: in all the same is true, scrolling is slow, saving is super slow, opening a site takes tens of seconds, saving a new file takes tens of seconds.

I created a 100% new site, and scrolling a page is in pauses.

[adamjimenez]

Do you have another device to try on? Does it make a difference if turbo mode is toggled on / off?

[frafor]

Bingo! In the iPad (a very old one, slow in almost anything) Shiftedit in the same file under Chrome for iPad, did move without the jumps, and typing text is just as slow as Chrome is regularly under this iPad. So, what next? I have tried closing all apps or windows programs and using only Edge with Shiftedit, and the slowness is there immediately.

[adamjimenez]

If you create a new file is it still slow? Or is it just for existing files? Do you have norton internet security or anything like that, that could be interfering?

[frafor]

My report for today:

1) PC Windows 10 was turned off 2) This morning, PC was restarted. 3) Before loading any apps, I opened Firefox, which renewed itself. 4) Opened Shiftedit and loaded my largest php file for editing. It was better than my previous experiences. Firefox did not use a correct ordering of files in the left-hand tree. I had to fiddle with it a little till it got it right. 5) Closed Firefox and opened Edge. Slightly faster than Firefox. Tree ok at loading. Biggest php file (about 4800 lines) was going from top to bottom in about 1.5 seconds. Still, not as fast as the notepad++, which is instantaneos 100%. 6) Opened Shiftedit in Opera; slow as slow can be. 7) About to open in Chrome: as slow as Opera. Impossible to work with. In Chrome, I opened a file from my Dropbox; the longest one. Still, as as can be. Impossible to work with.

So, that is the report.

Honestly, there IS a problem here. It won't be long before it starts affecting other users.

[adamjimenez]

I have a similar setup win10 64, chrome 68 and have no performance issues.

[frafor]

Touching HOME from the bottom or END from home, causes 5.6% of 4 cpus and 8 logical cpus to be in use for the Chrome task (15 GB of RAM!). 3.7% to open site; 5.2% to open tree first part; 7.8% to open large tree branch.

Edge: 9.4% to expand tree. Same file: 5.2% to open large file; 2.3% from top to bottom (opposed to 5.6% in Chrome), AND taking less than 1 second.

However, Edge takes less time (uses more CPU) than Chrome (uses less CPU but takes longer). Also, Edge is not multi-thread (?) but I will not be using Edge for anything but Shiftedit.

So, conclusion: Chrome has a problem:

Google Chrome is up to date Version 68.0.3440.106 (Official Build) (64 bits)

[adamjimenez]

We're on the same chrome version. Mine also hits 5% cpu when pressing home but only for a fraction of a second so that looks normal. Mine shows as using 251MB in memory footprint.

You could... go into Chrome dev tools (F12). On the performance tab press record and then go back to shiftedit and press home/ end. Then stop the record and then dig into the call tree to see what's taking the most time.

see screenshot:

[frafor]

Here is the problem:

[image: image.png]

That is what happens in Chrome after I hit TOP being at the bottom of a 4200-line file. 11 bursts, instead of one movement. Then, see this:

[image: image.png]

grey area 8211.9 ms (other). Why is that? Chrome needs to do "something" before it continues to move the file upwards? (or downwards?) What a hassle! I just need my time!

On Wed, Aug 22, 2018 at 12:58 PM Adam Jimenez notifications@github.com wrote:

We're on the same chrome version. Mine also hits 5% cpu when pressing home but only for a fraction of a second so that looks normal. Mine shows as using 251MB in memory footprint.

You could... go into Chrome dev tools (F12). On the performance tab press record and then go back to shiftedit and press home/ end. Then stop the record and then dig into the call tree to see what's taking the most time.

see screenshot:

[image: image] https://user-images.githubusercontent.com/573192/44481315-6014ec80-a63d-11e8-853c-37b05b6d5e94.png

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/adamjimenez/shiftedit/issues/322#issuecomment-415123124, or mute the thread https://github.com/notifications/unsubscribe-auth/AEgD2QjwX74YVGkDDnvtXqy9JgNdWsWBks5uTZvSgaJpZM4V9YKL .

[adamjimenez]

images not showing.. I just pasted my image into the github comment field.

[frafor]

Good news! Version 69. (Chrome) has solved the problem.

There was a scrolling problem, reported in several Internet forum sites discussing hundreds of issues.

The new Chrome version brought about other new issues, but one can work with it.

[adamjimenez]

Great!