I've noticed some performance issues with using Perl regular expressions for the function list as well. I left a tip in the "new perl function strings" thread. I'd be interested to know about any other constructs with sluggish performance that people may find.
Well, the Perl Regular Expression set is much richer than the unix/UE style, so the why I can understand. There is probably some overhead for initiating the external parser though. In theory it shouldn't be any slower.
(I'm personally very glad they added them, even if it makes things a little slower)
(I'm personally very glad they added them, even if it makes things a little slower)
The problem is not the Perl regular expression engine, which is plenty fast, the problem is the function string. Here is the PHP function string from the latest default wordfile:
The "(?s:.*)" part greedily matches all characters, including line breaks, so when the part of the pattern before that matches something but the rest of the pattern after that doesn't match anything this will greedily try to match the rest of the file (which will be slow, especially for large files).
Here's the Perl-style PHP function string I'm using, which is a direct adaptation of the previous UltraEdit-style PHP function string:
Code: Select all
/Regexp Type = Perl
/Function String = "^[ \t]*function[ \t]+([\w_\d]+)[ \t]*\((?s:.*)\)[ \t]*\{"Here's the Perl-style PHP function string I'm using, which is a direct adaptation of the previous UltraEdit-style PHP function string:
Code: Select all
/Regexp Type = Perl
/Function String = "^[ \t]*function[ \t]+([\w&]+)"
I'm sure, IDM has tested the Perl regular expression function strings. They have changed several times during beta test phase. Beta 2 has had a different Perl function strings than Beta 1 and the release candidate has had again different function strings. There were lots of problems with the Perl function strings during beta test period. The other Beta testers can confirm this.
Maybe your PHP files are simply coded completely different than the PHP files IDM has. After reading dozens of posts that a function string is not working for a user without adapting it to his coding style, I can say with 100% certainty that there will be NEVER, NEVER a function string for programing languages which allow dozens of variants in coding style which works for all users.
But where is your problem. You can adapt the function string to your needs. You must not use the defaults. I also do not use the defaults for C/C++ because they don't work for my embedded C files. So what is your problem? That IDM has not created a default which fits for you?
Okay, I agree with you that IDM should give the Beta testers more time for testing before the official release of a new version. 3 weeks is extremly short to test a bundle of new features. But you are also writing software. Do you not have deadlines and do you always fully test your software before you publish it? And how can such an extremly powerful feature like the Perl regular expression engine really be tested fully?
Maybe your PHP files are simply coded completely different than the PHP files IDM has. After reading dozens of posts that a function string is not working for a user without adapting it to his coding style, I can say with 100% certainty that there will be NEVER, NEVER a function string for programing languages which allow dozens of variants in coding style which works for all users.
But where is your problem. You can adapt the function string to your needs. You must not use the defaults. I also do not use the defaults for C/C++ because they don't work for my embedded C files. So what is your problem? That IDM has not created a default which fits for you?
Okay, I agree with you that IDM should give the Beta testers more time for testing before the official release of a new version. 3 weeks is extremly short to test a bundle of new features. But you are also writing software. Do you not have deadlines and do you always fully test your software before you publish it? And how can such an extremly powerful feature like the Perl regular expression engine really be tested fully?
Best regards from an UC/UE/UES for Windows user from Austria
We have verified that there may be an issue related to greedy matching as referenced earlier in this thread. Because of this, we have posted updated hotfixes on our site today for UltraEdit-32 v13.10 and UEStudio '06 v06.30.
This hotfix reverts to UltraEdit style regular expressions as the default for function strings in the wordfile. Perl style regular expressions may still be used if desired using the command specified in the Help files:
/Regexp Type = Perl
If you click on Check for Updates in the Help menu, a dialog will be presented that provides a download link for the latest hotfix version. Please extract the files in the zipped archive to the directory where UltraEdit/UEStudio was installed.
We will continue looking into the possibility of a performance issue related to Perl style regular expressions for the function strings and will correct this as necessary, but this hotfix provides an immediate solution for users seeing the reported issue.
Thanks, Troy
This hotfix reverts to UltraEdit style regular expressions as the default for function strings in the wordfile. Perl style regular expressions may still be used if desired using the command specified in the Help files:
/Regexp Type = Perl
If you click on Check for Updates in the Help menu, a dialog will be presented that provides a download link for the latest hotfix version. Please extract the files in the zipped archive to the directory where UltraEdit/UEStudio was installed.
We will continue looking into the possibility of a performance issue related to Perl style regular expressions for the function strings and will correct this as necessary, but this hotfix provides an immediate solution for users seeing the reported issue.
Thanks, Troy
