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?
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
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
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.
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.
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.
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
@Luca, i send information and a test case to support [at] iceteagroup.com. Did you recieve all info ?
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.
Please login first to submit.