I think I've just worked out what was eating processor in my EWB 2
conversion. I have a timer that gets a status every second, and forms a
String with line feeds etc for display in a TLabel which has word wrap
enabled. But it was taking way too long and starting to kill the
processor and make the page very slow to respond. So I have looked at
it, and found that the TLabel had "Autosize" set to true, but it was
also set to have its layout to fill the space. I turned off autosize,
and the processor eating is gone. At least it appears to have! I
imagine that EWB was spending time calculating and then not doing
anything effectively.

--

Matthew Jones

Matthew Jones wrote:

>  At least it appears to have!

Spoke too soon... More investigating to do.

--

Matthew Jones

Okay, new suspect, and probable fix:

I had this in my "Report" debug function:

 editDebugReport.Lines.BeginUpdate;
 try
    editDebugReport.Lines.Add(szMessage);

    while (editDebugReport.Lines.Count > 2000) do
       editDebugReport.Lines.Delete(0);
    finally
       editDebugReport.Lines.EndUpdate;
 end;

The CPU profiler indicated that this was taking a long time, and I'd
not output 2000 lines either. It has been replaced with:

       m_xReportList.Add(szMessage);
       while (m_xReportList.Count > 2000) do
               m_xReportList.Delete(0);
       editDebugReport.Lines.Text := szMessage;

This, so far, again, has not seen anything like the CPU use that it had
before. Lesson: Don't do lots of work with the DOM content as the
Javascript has to work too hard to get it back and forth. Having a
shadow item and just sending it to the DOM is far more efficient.

The auto-layout thing may have been a small part of it, or not...


--

Matthew Jones

Matthew,

<< This, so far, again, has not seen anything like the CPU use that it had before. Lesson: Don't do lots of work with the DOM content as the Javascript has to work too hard to get it back and forth. Having a shadow item and just sending it to the DOM is far more efficient. >>

Please email me/post all of the code that you were using.  If you were using a TMultiLineEdit control, then it will not update the underlying edit control's value until the EndUpdate.  IOW, it should be just as efficient as updating a TStrings instance not connected to anything.

<< The auto-layout thing may have been a small part of it, or not... >>

If you were using the TMultiLineEdit control, then it doesn't have an AutoSize property.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> Please email me/post all of the code that you were using.  If you
> were using a TMultiLineEdit control, then it will not update the
> underlying edit control's value until the EndUpdate.  IOW, it should
> be just as efficient as updating a TStrings instance not connected to
> anything.

That is the code, as a "Report" function, so that I can see what is
happening "underneath" my code.


>
> If you were using the TMultiLineEdit control, then it doesn't have an
> AutoSize property.

I had a TLabel showing status from the server, and the multi line edit
is used for the reporting so I can copy from it.

--

Matthew Jones

Matthew,

<< That is the code, as a "Report" function, so that I can see what is happening "underneath" my code. >>

What does a typical message look like ?

It may simply be the EndUpdate copying of the TStrings.Text back to the input value that is causing the problems.  You may want to look into using a TListBox or a TGrid instead - they are virtual and don't require such machinations because they are solely under EWB's purview.  In general, if EWB is doing it solely on its own, then it's fast.  If it has to interact with the DOM, then it will be slow.  That's why EWB goes to great lengths to only touch the DOM when it is absolutely, positively necessary.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> << That is the code, as a "Report" function, so that I can see what
> is happening "underneath" my code. >>
>
> What does a typical message look like ?

Report('Received response from server ' + szJSON');

Nothing fancy.

> If it has to interact with the DOM, then it will be slow.

I think that is the real cause. I call the Report function a lot and
some of the strings may be small, some may be long. Key of course is
that it had to read it, write it, and then do the limiting juggle. Now
it is all in memory and has cut most interaction with the DOM.

Fundamentally, cutting interaction with the DOM is something we have to
be aware of. The controls can do their best, but for big text
manipulation, it will always be better to read the whole lot,
manipulate it, and write it.

A list or other option would not work FWIW, as I often copy and paste
to an editor so that I can understand why my code is not doing what it
should (usually the JSON is not right or something).


--

Matthew Jones

Matthew,

<< Fundamentally, cutting interaction with the DOM is something we have to be aware of. The controls can do their best, but for big text manipulation, it will always be better to read the whole lot, manipulate it, and write it. >>

Yes.

<< A list or other option would not work FWIW, as I often copy and paste to an editor so that I can understand why my code is not doing what it should (usually the JSON is not right or something). >>

For the record, I really considered adding a custom, virtual, multi-line edit control in the initial release, but I just didn't have the time to fit it in.  I may end up doing something in this regard soon, and that would solve these issues once and for all.  You can't imagine what a relief it was to break free of the built-in listbox browser control with our own virtual TListBox.  It made everything so much easier to deal with, and you can add hundreds of thousands of items in just a few hundred milliseconds.

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> << Fundamentally, cutting interaction with the DOM is something we
> have to be aware of. The controls can do their best, but for big text
> manipulation, it will always be better to read the whole lot,
> manipulate it, and write it. >>
>
> Yes.

For the historical record, I've done more playing with this and Tim had
a look. Basically, browsers are poor at measuring their sizes, so if
you are going to be doing a lot of changing of edit boxes and probably
other components too, then you need to be careful. It's a browser
thing...

--

Matthew Jones

On 9/23/2015 11:22 AM, Matthew Jones wrote:
> For the historical record, I've done more playing with this and Tim had
> a look. Basically, browsers are poor at measuring their sizes, so if
> you are going to be doing a lot of changing of edit boxes and probably
> other components too, then you need to be careful. It's a browser
> thing...

UI operations are/have been expensive  - i recall a not dissimilar
performance issue we were troubleshooting maybe 5 years ago. Culprit was
good old VCL Memo bog and us doing logging 1 line at a time - it was dog
slow as well

"Everything old is new again"

Raul