Performance VGW vs WiseJ

1
1

We’re converted a Visual Web Gui application to WiseJ.  Application works well, but performance is much slower than in VWG application.

Screens built up 50 to 100%  slower in the converted application, we did several tests in different browsers but aren’t finding the root cause.

In the firefox \ performance recording  we noticed a record setTimeOut with a duration of ~638ms in the timeline, and it looks to be waiting on the action before continuing the rendering of the web page.

Anybody an idea how to speed up things?

 

  • You must to post comments
0
0

Hi Christian,

I tried. See performance log below. In Chrome hit F12 and enable Verbose logging (running in debug mode) and you will see all the internal logs in the console.

What this shows is that the payload for the initial creation of 801 controls (window + 800 children, of which now 400 are comboboxes…) was 554KB (compressed 11K, to see this you have to look at the websocket messsages in the network tab). To render the 801 controls it took the javascript code 1.3 seconds. When creating 400 PictureBoxes instead (see below) the time elapsed drops to 658ms. That’s because of the additional button widget in the combobox. I tried with 400 TextBoxes and the time is 615ms.

Once the javascript is done building the DOM, the painting time is the browser’s job.

 

If you need to create 400 combo boxes I’d suggest to: a) if it’s a repetitive pattern use the DataRepeater, b) if not, do not populate the items list at first, populate it when dropped down the first time; c) if you have many items enable the VirtualScrolling property (we have a project with 93,000 items in ComboBoxes that crash windows on the desktop and they work perfectly, also with the filter AutoCompleteMode with VirtualScroll=true, when false it also crashes the browser).

HTH

400 ComboBox + 200 Labels + 200 Panels

009043 Wisej: Process Response length: 554851
009058 Wisej: Process Actions count: 1
009061 Wisej: Process Action 3
010391 Wisej: Action Create created: 801
010395 Wisej: Process Action 4
010395 Wisej: Action Update updated: 0
010395 Wisej: Process Actions elapsed: 1337 ms

400 PictureBox + 200 Labels + 200 Panels

003102 Wisej: Process Response length: 436051
003118 Wisej: Process Actions count: 1
003121 Wisej: Process Action 3
003775 Wisej: Action Create created: 801
003776 Wisej: Process Action 4
003776 Wisej: Action Update updated: 0
003776 Wisej: Process Actions elapsed: 658 ms

 

  • Cristian Zerbinati
    ok thank you for tips :-)
  • Luca (ITG)
    BTW, there is a new feature scheduled for 2.2 that is available as an Experimental Feature in one of the next 2.1 builds for ComboBoxes and ListBoxes. They will have a new property LazyLoading and a new event Load, when you set LazyLoading = true the items are not sent to the client speeding up the initial creation even more. When the user drops down the combobox (or the listbox is shown) you get a small ajax loaded in the button (similar to the TreeNode LazyLoading already available) and it downloads the items only the first time.
  • You must to post comments
0
0

Hi Luca,

try replace the two picturebox with two combobox. The time increases significantly, even if they are empty. If you put some items the time increases considerably

bye

Cristian Zerbinati

  • You must to post comments
0
0

Actually I just noticed that while your test says 200 it is actually creating 800 controls: 200 panels + 400 picture boxes + 200 labels. The browser side timing shows 793ms (rendering frame). If I run the test with 200 controls I get less the 300ms on the browser and a total round trip of about 450ms. Which is on average the speed I observed on other projects:

800 controls: 800ms browser rendering, about 1.3 seconds (full round trip)

200 controls: 300ms browder rendering, about .5 seconds (round trip).

We can’t get any faster.

https://www.screencast.com/t/guu0nYx3Kld

  • You must to post comments
0
0

My tests show 93ms to create the controls and 730ms to process them on the client. When you show a message using the appear event you are adding the communication lag, which is another few milliseconds. The total for me is 1.3 seconds including the network time. You can’t make it faster than this and I don’t see the kind of not smooth or slowness that you mention in large projects I’m working on.

My experience with VWG controls is that the creation is faster and the management is slower. In any case, this is the speed we have and there isn’t any room to increase it since it’s browser rendering speed.

  • You must to post comments
0
0

We created a small (WsieJ 2.0 / visual studio 2017) test project to add a number of controls to a webpage (solution attached).

In our solutions a number of screens consist of 200+ controls. if we run the test program most of the time it takes around 100 ms to create the controls but around 2 seconds before the client browser shows them.

What can be done to speed up the displaying of the page ?

Combined with some processing time to get the data from the database server (between 200ms – 500ms depending on the data complexity)  browsing between screens isn’t smooth / to slow.

Please let me know how we can solve this.

 

 

 

 

  • You must to post comments
0
0

Hi,

I agree with Edwin. I was talking about it yesterday with my colleague… I have completed a porting of an VWG application and I’m forced to decrease the number of controls on the screen, otherwise the drawing times were too long.
initially I thought it was a code problem, but after a careful debugging I’m really sure that it is the drawing action that was very slow

Cristian Zerbinati

  • You must to post comments
0
0

@Luca, i send information and a test case to support [at] iceteagroup.com. Did you recieve all info ?

  • You must to post comments
0
0

VWG is slightly faster in the initial creation of a complex form because it used a large XSLT document transformed against the XML state into a big HTML string. It didn’t use any javascript widget nor event system. During runtime VWG is much slower because of the same reason. This has been my observation on several large VWG -> Wisej projects. Some forms these projects have about 1,200 controls and open in less than 2 seconds in Wisej.

Wisej on the contrary uses a complete javascript library of actual widgets, with a complete API, that build the UI in the browser using javascript objects, and manipulating the DOM using a FastDOM approach (dom changes are flushed in sync with the browser’s painting frames).

I don’t know of any timer that slows down the creation. It could be a firefox plug in blocking the javascript. If you want to send me a link privately send it to support [at] iceteagroup.com and I can take  look.

 

  • Edwin Somhorst
    @Luca, do you have some kind of update ? We spend a lot of time in converting and deployment is blocked by the performance issues.
  • You must to post comments
Showing 8 results
Your Answer

Please first to submit.