View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0037706||Lazarus||IDE||public||2020-09-05 12:37||2020-09-12 11:14|
|Reporter||wp||Assigned To||Juha Manninen|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||2.1 (SVN)|
|Summary||0037706: [Regression] IDE extremely slow when adding a new control to a heavily populated form|
|Description||This is a follow-up to issue 0037595 where I reported slow response of the menu editor in trunk versions beginning with r62635.|
Working on a project in which the main form contains a large number of controls I noticed that the issue is more general. When a new control is added to this form in the designer from the palette the border of the new control is drawn and the IDE remains unresponsive for some time. This time increases with the number of controls already on the form. When some cirtical control count is reached usefull working with this IDE becomes impossible.
This behaviour was introduced in r62635, reverting back to r62634 the new control added appears completely immediately, and there is only a very short delay.
|Steps To Reproduce||Try the demo program ImgViewer which comes with Lazarus (folder (lazarus)\examples\imgviewer). Load it into trunk (after r.62635) and add a TButton from the palette - I counted the time: about 40 seconds until the IDE was responsive again. And this is for a form which is not too heavily populated.|
|Additional Information||I have several trunk versions on my system (32 bit vs. 64 bit, FPC 3.2.0 vs 3.04.) - they all behave in the same way; therefore, I'd exclude the possibility that my trunk version is damaged in some way.|
I tested only on Windows (WIn 10).
|Tags||No tags attached.|
|Fixed in Revision|
I don't think this is related to 0037595. It was solved by r63802 and r63803 which modified only MenuEditor.
Maybe this is related to 0037688 which also happens on Windows. Somebody else should fix that. My development environment is not Windows. Reverting guilty revisions is difficult, too, because there are many affected issues.
I have just installed Linux Mint on VM, and the issue is there with linux as well.
I have also tested on my mac Mini; with same versions as outlined in issue 37688
It is much slower than previous version.
So it is not windows specific.
||Is it caused by r63842? I will test it soon, too.|
I wondered why nobody else is seeing this massive issue on Windows. Since my development Win PC is torturing me with blue screens recently i installed Laz trunk on a Notebook, also with Win10 (which never had seen Lazarus before) - and: the issue is gone. So I am inclined to close the issue from my part -- and I'll have to fix my PC; of course, I cannot speak for the observation reported by josh. On the other hand, it is hard to believe that PC issue like damaged system files, hardware etc, disappear when I revert the trunk revision to r62634.
If you were able to remove the issue by reverting I would say there is still a problem. So I wouldn't throw in the towel yet on your end.
It's possible your laptop is simply out performing enough to hide it and different video configurations can also be causing differences of operations.
You should install one of the official releases like 2.0.10 and see how that works with a large count of controls on your ailing PC because if Laz IDE or Large number of controls in a LAZ app is the only thing in your PC that is crawling like that, I would say something is still wrong.
I don't run the trunk because I've never succeeded in being able to get any one my PC's at this location setup to sync with the files without all sorts of issues.
@wp, is this possibly a duplicate of 0037593?
It was fixed a long time ago in r63791 and r63792.
@josh, adding a new control to a form is different from resizing a form.
Are you sure you can reproduce this issue, or are you explaining issue 0037688?
> @wp, is this possibly a duplicate of 0037593?
> It was fixed a long time ago in r63791 and r63792.
I know. But since I observed the issue of 0037593 with the main menu I wrote a demo program using a menu, and thus you fixed an issue related to a menu. But what if the real issue introduced by r62635 is still unsolved?
I am unclear what leads to the issue reported here. As noted, a clean installation of Laz trunk (with FPC3.2 taken from Laz 2.0.10) on a rarely used old Win10 notebook does not show the issue. On my main development machine I did a clean trunk installation, too, the issue persists but to a smaller degree: adding a TButton to the imgViewer example project takes 9 sec in the fresh installation ("fresh = after "make bigide") while it takes 16 sec in my normal installation.
Since the normal installation contains also the packages that I work on, the number of packages/components installed could fold into this issue. So, I added JVCL (which contains tons of components) to the fresh installation and the test time increased from 9 sec to 12 sec. Alternatively I uninstalled JVCL from the normal installation and the test time decreased from 16 to 13 sec. For comparison: the trunk installation of r62634 takes only 1-2 sec, with or without JVCL (similar to Lah 2.0.10 - your question, jamie)
So, I think it can be concluded that the time for the IDE to become usable after adding a button to the ImgView demo on the affected installation depends also on the number of components installed.
Still not clear what makes the difference in the notebook installation, it is always faster than the PC and there is only a marginal change on adding JVCL. There are some unmentioned differences, though, which still have to be checked: The notebook does not yet have the 2004 update of Win 10 (the PC has), and the notebook installation is 64 bit, while my workhorse installation on the PC is 32 bit.
I am wondering whether you are hitting the amount of GDI object handles that windows handles per sesion ( you can alter this). IIRC the default is around 10K, also IIRC windows itself has a limit of 64K Object Handles.
Each UI Control in a Form is allocated at least one User Object Handle.
You can use task manager to show the amount of gdi handles (although other third party utilities do a better job). Open TaskManager Click the Details TAB and look under the Handles Column.
I just had 2004 Win 10 updates on a I5 Win pro and I5 Home..
Tested with 2.0.10 release, 2.0.8, 2.0.6 and 2.0.4 with a app that has lots of controls on the form. they all work great and the ide isn't really having any issues different now than it ever did. I get a 1..2 sec delay max on most OI interactions with a densely populated set of forms.
The only Delay I get and its always been there is when I drop the first initial control on a form when firing up the IDE. It could be a blank form and it does not matter.
but after that, it streams along just fine.
I know - the issue does not show on any release version, only on trunk after r62635
Assuming I am hitting the GDI object handle count limit, then why don't I when I revert trunk to r62634 (this last revision which was ok)?
> I don't run the trunk because I've never succeeded in being able to get any one my PC's at this location setup to sync with the files without all sorts of issues.
Install TortoiseSVN. Create a folder for Laz trunk (c:\laz-trunk), right-click the folder, select "SVN checkout" and enter the Laz trunk repository URL (https://svn.freepascal.org/svn/lazarus/trunk/components) - download the trunk sources. Write a batch file which (1) sets the path to a folder with a valid fpc.exe 3.2.0 (or 3.0.4), and (2) calls "make bigide". Execute the batch. When the process is finished add a file "lazarus.cfg" to the Lazarus folder (c:\laz-trunk\lazarus.cfg) with the content "--primary-config-path=path_to_lazarus_config_folder" (adapt "path_to_lazarus_config_folder" to your situation). Run Lazarus - the introductory dialog urges you to define the location of the fpc.exe to be used and where to find the debugger - use data from an existing Laz 2.0.10 installation. Finished. I did this many times, and it works.
|2020-09-05 12:37||wp||New Issue|
|2020-09-05 12:37||wp||Relationship added||related to 0037595|
|2020-09-05 12:38||wp||Assigned To||=> Juha Manninen|
|2020-09-05 12:38||wp||Status||new => assigned|
|2020-09-06 00:54||Juha Manninen||Note Added: 0125400|
|2020-09-06 10:30||wp||Assigned To||Juha Manninen =>|
|2020-09-06 10:32||wp||Relationship added||related to 0037688|
|2020-09-06 12:32||Juha Manninen||Status||assigned => new|
|2020-09-06 12:32||Juha Manninen||LazTarget||=> -|
|2020-09-10 15:13||josh||Note Added: 0125461|
|2020-09-10 17:29||Juha Manninen||Note Added: 0125462|
|2020-09-11 00:01||wp||Note Added: 0125468|
|2020-09-11 01:07||jamie philbrook||Note Added: 0125469|
|2020-09-11 09:07||Juha Manninen||Relationship added||related to 0037593|
|2020-09-11 09:09||Juha Manninen||Note Added: 0125473|
|2020-09-11 09:10||Juha Manninen||Note Edited: 0125473||View Revisions|
|2020-09-11 09:16||Juha Manninen||Note Edited: 0125473||View Revisions|
|2020-09-11 09:17||Juha Manninen||Assigned To||=> Juha Manninen|
|2020-09-11 09:17||Juha Manninen||Status||new => feedback|
|2020-09-11 11:21||wp||Note Added: 0125476|
|2020-09-11 11:21||wp||Status||feedback => assigned|
|2020-09-11 12:51||josh||Note Added: 0125477|
|2020-09-11 23:35||jamie philbrook||Note Added: 0125493|
|2020-09-12 11:02||wp||Note Added: 0125502|
|2020-09-12 11:04||wp||Note Edited: 0125468||View Revisions|
|2020-09-12 11:14||wp||Note Edited: 0125502||View Revisions|