Menu
▾
▴
#53 Slow response when editing PHP files
closed-fixed
5
2005-07-12
2004-10-06
No
When editing PHP files with colorer-take5.beta3 I
noticed there's significant delay before input symbols
will be displayed, it's not very large, about 0.3-0.5
sec. Anyway, it's more then 0.1 sec (this value is the
maximum delay recommended by usability guides), so edit
become rather irritating.
And, moreover, such delay wasn't in previous version of
take5, i.e. beta2. So I had to downgrade to this version...
Btw, I used rather small PHP files to edit - 1-2 KB.
Logged In: YES
user_id=313042
Are you sure this is Colorer beta3 problem? Can you check this
on clean FAR w/o any other plugins?
Logged In: YES
user_id=951610
Yes, I'm sure. I reverted back to beta2, and there's no such
problem anymore. It's the only plugin I changed in my plugin
list.
Just for any case: I'm using Far 1.70b5 on WinXP + SP2,
Athlon XP 1.11 GHz, 512 MB RAM.
Logged In: YES
user_id=951610
Sorry, I tried without any other plugins and this behaviour
disappeared - apparently some other plugin somehow slows
down beta3. It's just strange this problem wasn't occured
with beta2...
Anyway, I assume it's not your fault. :)
Logged In: YES
user_id=313042
I think this is some kind of data input/filtering plugin... Possibly
it conflicts with beta3 it some way...
Logged In: YES
user_id=951610
Sorry to bother you again, but I was wrong - this delay is
still here, even w/o other plugins. Maybe I'm just typing
too fast? :)
I noticed this delay when I was typing "require_once" PHP
keyword - I'm not sure will the delay present when typing
not keyword, but it's definitely here for keywords.
I think possibly it's because PHP *.hrc files size increased
from 64KB to 230KB?
Anyway, PHP parsing is too slow now.
Logged In: YES
user_id=313042
I'll try it on slow CPU.
You can try to decrease number of PHP keywords supported...
Logged In: NO
I still use Colorer 3craze because last version of this
programm tryed to grab much resources. Far works is slowly.
Other problem of all versions of Colorer is that the plugin not
works when php-file has a more than 2000 strings.
Testcase
Logged In: YES
user_id=951610
I think I found out why Colorer sometimes slows down with
PHP files. I attached test file, try to type some code after
each of 2 comment lines to compare speed. Type code, because
inside string constant tokens performance is always good.
Hope it'll help.
Logged In: YES
user_id=313042
I think I found the root cause. The problem is in too much
spaces, used for alignment. There is a some construction
in PHP HRC, which cause heavy computations on these
empty spaces. I'll try to find it and resolve this
performance issue. Thanks for good code sample.
Logged In: YES
user_id=951610
Yes, I thought about spaces too... Also note that _before_
space-aligned lines performance is poor, but after them
everything's OK. Suspect it's due to the way you're parsing
the file.
Logged In: YES
user_id=313042
Performance improved via changing outline php logic.
Much faster, but not yet a chopper...
For now closing the issue.
Fix is available since eclipsecolorer 0.7.1