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?
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.
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).
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
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.
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
Please login first to submit.