Great!! Any measurements how much aster it shuld be now?
Win - It takes significant time to show a DetailView with a large number of editors
Answers approved by DevExpress Support
We have fixed the issue described in this ticket and will include the fix in our next maintenance update. To apply this solution before the official update, request a hotfix by clicking the corresponding link for product versions you require.
Note: Hotfixes may be unavailable for beta versions and updates that are about to be released.
- v18.1.3Download Official Update
- v17.2.6Download Official Update
- v17.1.10Download Official Update
thx for the fix Dan - as we are currently rolling out our next release positive feedback is coming now from users and also from internal testing! So Looks perfect - while there is still one Situation where Performance could be better. Dennise should know the situation - it happens when the detailview contains 3 or 4 nested listviews - this configuration is the slowest of all our tests. would be great if this could also optimized as that would be the last area where it lacks performance.
thx
Noxe
I'm happy to hear about these results in a real world application and thank you for informing us about the next slowest scenario.
We will see how to improve this situation, though I cannot promise any time frame. Nevertheless, thank you for your feedback. I greatly appreciate your cooperation.
would be interessting if you can optimize this - you know we struggled with that some time ago here: T461614 ;)
Yes, we found new details and decided to research this issue again. We cannot promise anything at the moment, though. This issue is complex, but our developers will do their best to find a solution.
Hi Uriah / Dan - just wanted to ask if there are any news on this issue? we are currently plannig 17.2 upgrade - and wondering if it is worth to wait for this ticket…
Hi Martin,
I am afraid that we do not have any news yet. Our developers are working on this task, but we cannot provide the time estimate at the moment.
Hello, I would like to share my experience with this, hoping this could help. This is really a headache, I'm in the same situation and with web application, complex detail opening performance is a little bit worse. I have improved it (few milliseconds) splitting details into 2 or 3 variants and adding an image to the variants ChoiceAction (still not very UX but better than only a caption), but is not enough. The web application runs in a very fast CPU Cloud server with at least 2000IOPS disk, and access to complex detail takes CPU up to 40-50% (not so bad) and 100% of disk during several seconds. Navigating through tabs is also very slow.
Casually I check the same application deployed into a slower VPS server with very fast SSD disk and performance is much more better.
So I decided separate database of fast CPU cloud server into a second fast CPU server with very fast SSD disk. I was pretty sure that then it was gonna be faster than the all in one VPS slower server… but… Surprise!!! performance is still worst than the slower VPS server with SSD disk and both, application and database on the same server.
Analyzing in detail, the fast CPU server without database, still put the disk usage at 100% and CPU at 40-50% when opening complex detail view, so I have to conclude that nevermind where the database is because the real bottleneck is excessive disk operations when rendering the view, even with database in another fast server with very fast SSD disk. So the only way to improve this is using SSD disk on the application server.
Saying that, in my opinion, devexpress XAF team should focus on identifying why so much I/O operations are needed to draw the layout and how to improve it.
I'm not sure if I've explained correctly. My test has consisted on deploy the application using a 2 servers arquitecture:
1- First server is the application server without database: Very Fast CPU with fast 2000 IOPS disk. ConnectionString points to second server and connectivity between both server is perfect.
2- Second Server is dedicated only to Database purpose. Very Fast CPU with very fast SSD disk.
So all database operations are performed at second server. This is the preffered arquitecture and is still slower than running the application and the database (both) in a slower (but also fast CPU) VPS with SSD disk (note that VPS share CPU so equal processor is slower than dedicated Cloud), and VPS runs application faster than the above better arquitecture approach. Obviously, adding an SSD disk to first server becomes application faster than VPS but it reveals an I/O performance problem with layouts.
Hello José Enrique,
Thank you for sharing your findings. However, the cause of the performance issue with DetailViews in a Win application is different than in a Web one. I've created a separate ticket on your behalf to discuss the issue you described: T595701: Web DetailView performance is slow because of the excessive amount of IO operations. I will reply in that ticket shortly.