Hi,

I was doing some test programming for android.
The android SDK unit contains 68000 lines (.pas and .inc together). Opening it in the IDE (by right-clicking an identifier in my sources) virtually stops the IDE.

The source of the android include file are drawn, but the scrollbars are not drawn, scrolling or navigating the source does not work, and the IDE is generally totally unresponsive. Only closing the tab again makes the IDE responsive. (and even the closing takes a while).

All this is on Linux, GTK, 64-bit, Lazarus from yesterday.

Has anyone else experienced similar problems ?

Michael.

Yes, me of course :D (also x86_64-linux, though the IDE is from around the beginning of the year)

Though it was bearable as I moved my Android development to my rather powerful machine (because JVM compilation is rather slow and also blocks my single core main computer -.- ) and used it through X11 forwarding...

Regards,
Sven

My PC is an 4-core machine ?
It should be able to handle this with its fingers up its nose, I would think...

It's clearly an issue in drawing, because the code completion seems to work fine.

Michael.

<michael.vancanneyt at .....> wrote

It should be able to handle this with its fingers up its nose, I would think...

I can't say I heard that one before. :-)

Where can I find this unit and include file? Is it part of the FCL?

If someone had to go on the drawing of the editor, please someone, consider to put lines to show block structure if an option is marked, like the cnpack does in delphi. I`m aware this is an complicanting of it, but is also a good feature that many likes.

Here
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/jvmbackend/rtl/android/jvm/ files "androidr14.pas" and "androidr14.inc".

Regards,
Sven

Where's that unit ? I'll try with qt under linux.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120215/c6348c41/attachment.html>

W dniu 15.02.2012 09:14, Michael Van Canneyt pisze:

All this is on Linux, GTK, 64-bit, Lazarus from yesterday. Has anyone else experienced similar problems ?

Just checked, both files load and display seamlessly. Navigation and search work like a charm.
I'm on Phenom 4 core, 4 GB RAM, Ubuntu 10.04.

stootch

W dniu 15.02.2012 13:12, stootch pisze:

I'm on Phenom 4 core, 4 GB RAM, Ubuntu 10.04.

I forgot to mention: Lazarus from today, 64 bit as well.

stootch

zeljko hat am 15. Februar 2012 um 12:44 geschrieben:

Mattias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120215/111b1d6c/attachment.html>

Yes, sorry...

Yes, I was surprised to notice it.

Especially since on the last Lazarus day, Martin had been doing some work on it. Since Sven Barth also has it, there must be something special going on.

> > Maybe the android unit uses some specials.

Well, it's full of Java import classes. The target is set to jvm, and as far as I know, the ide 'understands' that. I have also most automatisms (folding etc). switched off.

Anyway, Sven posted the URL where it can be found.

Michael.

Everton Vieira wrote

If someone had to go on the drawing of the editor, please someone, consider to put lines to show block structure if an option is marked, like the cnpack does in delphi. I`m aware this is an complicanting of it, but is also a good feature that many likes.

I don't know cnpack for Delphi, but I presume you mean the vertical lines connecting begin/end blocks. If so, there is a way to get a similar effect in Lazarus. This is what I have done for Lazarus Trunk (I also have a patch for Lazarus 0.9.30.x if you need).

In synedit.pp change the value of SYNEDIT_DEFAULT_VISIBLESPECIALCHARS to vscTabAtFirst. Recompile Lazarus. Then enable "show special characters" in the editor options. If you use TAB indentation (like I do), instead of 2xSpace indentation, then by increasing the tab width enhances the visual effect. See attached screenshot.

Sven Barth wrote

Here http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/jvmbackend/rtl/android/jvm/ files "androidr14.pas" and "androidr14.inc".

Thanks.

Tested here under Lazarus 0.9.30.1 r33214M FPC 2.5.1 x86_64-linux-gtk 2 and it works fine performance wise. But I can say that while I'm in the *.inc file and I do a "Unit Info -> Go to include directive", it goes to the wrong line of code in the *.pas file.

You should use trunk for JVM related units. 0.9.30(.x) can not handle the JVM specific differences and language extensions.

Regards,
Sven

Oh, and switch the IDE to "platform JVM" and "target Android" then.

Regards,
Sven

Hm. You use a very old lazarus.

Here at work (an older lazarus than at home, 34764) it opens the file without speed problems.

But the codetools don't work. I can't jump to ADSSqliteOpenHelper in the following code snippet from Sven Barth's Trainlog example (traindata unit)

Type
   TTrainLogHelper = class(ADSSqliteOpenHelper)
   strict private
     function GetNameOfTrainFamily(aID: jlong): String;

So something is still not OK. My .xsession-errors gives:

home/michael/FPC/jvmbackend/rtl/android/jvm/androidr14.pas" ### TCodeToolManager.HandleExcption: ": expected, but 'java.lang' found" at Line=11763 Col=35 in "/home/michael/FPC/jvmbackend/rtl/android/jvm/androidr14.pas" ### TCodeToolManager.HandleException: ": expected, but 'java.lang' found" at Line=11763 Col=35 in "/home/michael/FPC/jvmbackend/rtl/android/jvm/androidr14.pas" ### TCodeToolManager.HandleException: ": expected, but 'java.lang' found" at Line=11763 Col=35 in "/home/michael/FPC/jvmbackend/rtl/android/jvm/androidr14.pas" ### TCodeToolManager.HandleException: ": expected, but 'java.lang' found" at Line=11763 Col=35 in "/home/michael/FPC/jvmbackend/rtl/android/jvm/androidr14.pas" ### TCodeToolManager.HandleException: ": expected, but 'java.lang' found"

Which means it can't grok things like
   JLStringBuffer = class external 'java.lang' name 'StringBuffer';

Maybe the difference in speed is that the code tools now understand more and are therefor slower ?

Michael.

<michael.vancanneyt at ... wrote

Hm. You use a very old lazarus.

If it ain't broken, don't fix it. :-) This applies doubly so to Lazarus - though I do have a couple of my own fixes or mods applied [itches need to be scratched every now and again].

But the codetools don't work. I can't jump to ADSSqliteOpenHelper in the following code snippet from Sven Barth's Trainlog example (traindata unit)

Ah, I can't jump (Ctrl+LeftClick) in code either. But that might be due to Sven's comment - 0.9.30.x is not meant to be used with JVM code.

This does not help if some features that one needs (or wants) are only implemented in trunk... (yes, I'm aware that one could merge manually, but it's far easier for me to just use trunk)

Jupp... if you look back at this thread
http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-December/069446.html you'll see that I bothered Matthias quite a bit for getting Lazarus up to date with JVM development. :)

Regards,
Sven

hat am 15. Februar 2012 um 12:17 geschrieben:

[...] > Though it was bearable as I moved my Android development to my rather > powerful machine (because JVM compilation is rather slow and also

blocks my

> single core main computer -.- ) and used it through X11 forwarding... My PC is an 4-core machine ? It should be able to handle this with its fingers up its nose, I would

think...

It's clearly an issue in drawing, because the code completion seems to

work

fine.

No, here the codetools and synedit are fast with the android unit. The problem is the code explorer.
Maybe the recent changes to TTreeView.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120215/1dbe7885/attachment.html>

Mattias Gaertner hat am 15. Februar 2012 um
15:26 geschrieben:

Yes. It is TLazAccessibleObject.GetChildAccessibleObjectWithDataObject. It uses a linear search for the 10.000 items. I will replace it with an avl tree.

Mattias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120215/2481a04e/attachment.html>

Mattias Gaertner wrote

Yes. It is TLazAccessibleObject.GetChildAccessibleObjectWithDataObject. It uses a linear search for the 10.000 items. I will replace it with an avl tree.

Exact point.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120215/1257db55/attachment.html>

So - as workaround - closing the code explorer will fix the problem too. Cannot remember whether I had it open yesterday, but it is good to know :)

Michael.

zeljko hat am 15. Februar 2012 um 16:48 geschrieben:

The avl tree reduced it to half a second here.

The code explorer still needs a lot of time on this unit, because it creates 60.000 nodes and for each node it creates a description. Maybe the descriptions can be created on demand and only for visible nodes.

Mattias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120215/e412ef6f/attachment.html>

Thanks for doing the AVL fix =) I will study it and see if I can substitute FPList in some other projects too with AVL tree.

2012/2/15 Mattias Gaertner :

The code explorer still needs a lot of time on this unit, because it creates 60.000 nodes and for each node it creates a description. Maybe the descriptions can be created on demand and only for visible nodes.

It might be quite hard to do that without affecting accessibility potentially. The information needs to be passively available, just like in the screen where you see anything which fits, in accessibility the accessible software might also demand immediate access to the information and navigate around it even without any input to the software. So it might want to read even invisible stuff. We could add callbacks and change the creation to on demand, but I wonder if it is worth to complicate the code (which already was quite problematic to get working on Carbon). Maybe we should simply add a property to turn off accessibility for objects like the code explorer, which creates huge amounts of items and wants to optimize for speed. And add an option to turn accessibility for it on for those that need.

Il 15/02/2012 09:14, Michael Van Canneyt ha scritto:

I was doing some test programming for android. The android SDK unit contains 68000 lines (.pas and .inc together). Opening it in the IDE (by right-clicking an identifier in my sources) virtually stops the IDE.

Don't know if this is related, but I used a StringList component to display some text in a Lazarus project months ago and it worked fine with texts about 10.000-30.000 lines long, but went incredibly slow, pratically freezes, when I loaded an 85.000 line textfile. I wonder if something in TStringList internals goes really bad when has more than 65.536 lines?
Maybe this problem afflicts the lazarus IDE too...

Never heard of such a problem.
Please create a bug report.

Maybe this problem afflicts the lazarus IDE too...

Mattias

Known problems (also on Delphi):

- TStringlist typically uses twice the amount of RAM needed.
- Insertion into a sorted tstringlist gets very slow in the beyond 100-200kstrings magnitude.

Massimo Soricetti wrote

I wonder if something in TStringList internals goes really bad when has more than 65.536 lines? Maybe this problem afflicts the lazarus IDE too...

Yes, it is a known problem, and why Lazarus IDE uses TTreeview in many places like the Messages dialog, instead of TStringGrid.

A few months back (maybe even a year or more) I reported this issue too. fpGUI's StringGrid can create 8mil populated rows or columns in an instant. LCL took....well, it never finished after 4 hours on a quad core system - then I killed the test app. :) I'm sure if you search the mailing list archive, you will find that message thread.

Sven Barth wrote

This does not help if some features that one needs (or wants) are only implemented in trunk... (yes, I'm aware that one could merge manually, but it's far easier for me to just use trunk)

Stability is more important to me than the latest eye-candy. I use Lazarus (and MSEide) for work. I don't have time to fight with newly introduced bugs, which appear constantly in Lazarus Trunk. The stable branch 0.9.30.x has everything I need to get my work done - uninterrupted. I only made some mods to synedit (visual improvements and better TAB character support), and runtime customisable File Open filters.

Try Git, it makes merging between branches, or keeping local mods up to date, much easier than SVN.

Il 15/02/2012 23:14, Graeme Geldenhuys ha scritto:

Yes, it is a known problem, and why Lazarus IDE uses TTreeview in many places like the Messages dialog, instead of TStringGrid.

Well, at least there is a workaround for the problem :-)

TStringGrid in messages?

Funny idea. What editor uses a grid to show lines of text?

Who needs 8 million rows in a string grid?
I tried 1 million and it took 4 secs.

8 million created an endless loop and out of memory. Maybe the grid should define a maximum.

Mattias

What problem?

Mattias

Il 16/02/2012 03:21, Mattias Gaertner ha scritto:

TStringGrid in messages? Funny idea. What editor uses a grid to show lines of text?

[ ... ]

Who needs 8 million rows in a string grid? I tried 1 million and it took 4 secs. 8 million created an endless loop and out of memory. Maybe the grid should define a maximum.

I see your point.
Nonetheless, as you say, either it defines a maximum or behaves better when filled up with many lines: suddenly misbehaving without any warning is treacherous :-)
This should be put in LCL documentation.

Firstoff: I understand your reasons. But mine are also valid: trunk contains many feature that make my life easier. Especially full support for FPC 2.6.0 or newer (I don't know whether you patched your 0.9.30.x or not), support for generics and helper types (mostly because I develop them and only secondly, because I use them). Recently also the support for the JVM language extensions and then little gems like this: http://bugs.freepascal.org/view.php?id=21047 (look also at the comments, to see what I mean). This improves my workspeed when converting C code (which I like to do ;) ) a lot.

Try Git, it makes merging between branches, or keeping local mods up to date, much easier than SVN.

I like Git (I used git-svn when working on the generic improvements in FPC), but as I said: I personally(!) prefer to use trunk. And thus my workflow is usually this (this way I can be sure that I get the latest changes... a git mirror might be out of sync):

cd /mnt/data/subversion/lazarus
svn up
svn export . /mnt/data/applications/lazarus/0.9.31-new cd /mnt/data/applications/lazarus/0.9.31-new
make all OPT="-dWithSynInfo -dWithSynOverviewGutter -Xg" [Testing new lazarus and if okay:]
cd ..
rm -r 0.9.31-old
mv 0.9.31 0.9.31-old
mv 0.9.31-new 0.9.31

Maybe somewhen I'll pack the two parts into a lovely script (maybe using instantfpc) and that's it :)

Regards,
Sven

Mattias Gaertner wrote

TStringGrid in messages?

Yes, I believe the Messages window used to use a StringGrid (or was that a ListView or ListBox?).

Funny idea. What editor uses a grid to show lines of text?

Funny idea, what editor uses a TreeView to show lines of text (and not representing a tree)?

Who needs 8 million rows in a string grid? I tried 1 million and it took 4 secs.

I can't remember how the 8 million figure came up. I was implementing a log viewer and the applications I used, generated a crap load of log entries very fast. The LCL app couldn't keep up ran at 100% CPU load for over three hours without displaying anything.

Jesus confirmed the problem, but it was a low priority for him to look into. For the full message thread you are welcome to read the following:

http://thread.gmane.org/gmane.comp.ide.lazarus.general/46420/focus=46439

From the replies in that thread, it seems ListView had similar

problems, but I don't recall ever testing that personally.

As for your comment about why use a StringGrid. It is one of those components that are greatly underestimated (if it performs well - which the fpGUI one does). I use StringGrid components extensively in all my applications. I also use custom painting to make grids not always look like grids or at lest very different to a stock standard TStringGrid.

TListBox. But that was too slow on some widgetsets.

> Funny idea. What editor uses a grid to show lines of text? Funny idea, what editor uses a TreeView to show lines of text (and not representing a tree)?

There are plans to show several levels.

Grids are very flexible. I don't know if they are underestimated. There many grid controls for Delphi with the hundreds of properties and there are many boring programs using grids, so IMO grids are often overestimated as user interface.

Mattias

That's because of model/view architecture (at least under qt) . I think that we should think about adding TVirtualStringTree into lazarus as default component and use it at such critical places. There you can put 100M records in a msec, and also you can draw whatever there.

In my apps I'm using virtualstringtree in modules whenever I expect > 100 items on screen, otherwise listview / stringgrid fits ok.

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120216/3e130d08/attachment.html>