Hi

Shouldn't the BeginUpdate and EndUpdate in TMemo.Lines prevent the GUI from updating, thus allowing quickly adding many lines?

I made a test app which generates a big amount of random data and has 2 methods to add it to a Memo.
1. uses a temporary StringList and finally calls Assign.
2. adds the strings directly to Memo.Lines between BeginUpdate and EndUpdate.

Method number 1. is about 40 times faster!
I expected method number 2. to be the fastest.

The strange thing is that Assign() also uses BeginUpdate and EndUpdate, and then calls AddStrings() which has its own BeginUpdate and EndUpdate.
IMO it should behave identically with Memo.Lines.Add inside BeginUpdate / EndUpdate.

I can send the test app if needed.

Juha

OK, finally you have put a TMemo on a form.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130308/a42343bd/attachment.html>

2013/3/8 Juha Manninen :

Hi Shouldn't the BeginUpdate and EndUpdate in TMemo.Lines prevent the GUI from updating, thus allowing quickly adding many lines?

Yes.

Why? There is lot of comminucation between the LCL and widgetset, even if the widgetset doesn't paint any update with method 2.

It is different and noticeable.

Vincent

Ant?nio wrote

OK, finally you have put a TMemo on a form.

:)

I have put many Memos on many forms, but IIRC I did not add 200000 lines to them.
I was planning to write you on forum and verify your findings. Hold on...

Juha

Well, I would consider this as a bug. A 40 times difference is big! I have used BeginUpdate / EndUpdate often and they usually help to obtain a fast GUI. I didn't make exact timings though. Now, is this a well known issue and the right way is to always assign data from a temp list?

Juha

2013/3/8 Juha Manninen :

It helps some to use beginupdate / endupdate. But a TStringList is a better place to build strings than a TMemo.

Now, is this a well known issue and the right way is to always assign data from a temp list?

Only if you are changing it a lot.

Vincent

I don't know in case of a TMEmo, but I guess there will be similar reasons. Consider that with a SynEdit.

If you insert/add lines to a SynEdit (inside BeginUpdate), there is still work it needs to do.
Like it you insert before the caret, then the caret must still move. It will not be painted, but it must move. If wait and try to do that after EndUpdate you may get a different position.

Examble: caret is one before end of line, and caret is not allowed past EOL BeginUpdate
abcdef|g
delete some chars at begin of line (caret moves
f|g
insert at EOL
f|g123456
EndUpdate

But if you did not move during BeginUpdate he caret then it would end up on a diff position.
Actually accessing SynEdit.Lines will skip that, But thats another story....

Point is the widget may have reasonable work to do, even if Updating

Quoting Juha Manninen :

That highly depends on widgetset. I guess that you're talking about qt
widgetset.
Qt is pretty slow since we do our management of cursor (caret) moving
inside QTextEdit , but if you do bulk load of gazillion of lines then
such code helps:
Memo.beginUpdate;
Memo.WordWrap := False;
for i := 0 to SomeNumOfLines do
   Memo.Add(blabla);
Memo.WordWrap := True;
Memo.EndUpdate;
Of course this helps if you really set WordWrap := True; and you use qt ws.
Gtk2 is much faster in this case.

z.

Because here (1) the number of entries to add is known in advance, memory can be pre-allocated (Capacity). Not so when individual strings are added (2).

The behavior also depends on the widget, whether it stores one text (string) or multiple lines. A Windows Memo stores text, so that the fastest solution could be

   Memo.Text := StringList.Text;

DoDi

Al 08/03/13 15:35, En/na Martin ha escrit:

I don't know in case of a TMEmo, but I guess there will be similar reasons. Consider that with a SynEdit.

FWIW (and somewhat tangential to this topic) I was using TMemo to show events like this:

IF LogMemo.Lines.Count>5000 then
  LogMemo.Lines.Delete(0);
LogMemo.Lines.Add(NewMessage)

Until I found out that, under windows, it was dog slow. I switched from TMemo to TSynMemo and the above is an order of magnitude faster.
Under Linux-gtk I saw no noticeable difference between the two. That was with 0.9.30, didn't re-test with later versions.

Bye