Application sluggish after face lift with DevExpress Bars

I recently gave a mature project a facelift with the ExpressBars 6 suite from DevExpress.  I changed out the menus and toolbars and the application looks much better.  Everything went pretty well until one of my users noticed that some operations took longer with the new version.  I found this strange, since the code in question had not been altered, nor did to do any GUI stuff.  For example, one action is to import data from an Excel file.  In the old version it took about 3.5 seconds.  In the new version, it takes about 7 seconds.

I started investigating (thinking there must be some overhead threads) but have been puzzled.  I wrote a test rountine that I call from the old source base and the new source base.  (Same code, same .dcu)  The newer version is definitely slower.  

Any ideas on how I can track down the offender?  Both projects were compiled with Delphi 2007 (with optimization).
LVL 1
roknjohnAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Geert GOracle dbaCommented:
the only real way to find out what is happening would be to use a tool like profiler
http://www.prodelphi.de/indexpd.htm

it logs all procedures (and the time spent on each) passed through

with that you would immediately find the culprit
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Geert GOracle dbaCommented:
it may that you have 2 functions (or procedures) with the same name
and you are accidently calling the devexpress func/proc

put your unit last in the uses last to solve this
0
ziolkoCommented:
is only performance of Ecel down?
DevEx toolbars and mainmenu are hooking into windows messages and sometimes it can impact overall performance of your app

ziolko.
0
Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

roknjohnAuthor Commented:
Thanks to both of you.

I used this as an excuse to purchase AQTime.  It does appear that the the DexExpress controls are hooking into several system processes.  The culprit is the dxBarWndProcHook that is causing significant delays in all areas of my project.

I was able to tweak my code in a couple of specific areas, but overall it is still noticeably slower than before.

Here is one particular fix that helped a lot.  In a large loop (iterating through 10K-100K records), I was referencing a TCheckListBox (Items.Count=10) on another form.  Basically, for each iteration of the main loop, I needed to perform an action for each item that was checked in the list.  Example code below.  This referencing was very time consuming.  My workaround was to parse the CheckListBox once and build an array of checked item indexes to be used inside the main loop.  This greatly reduced the number of calls to the hook above.

I have logged an bug report with DevExpress.

I will split the points if that is OK.
for ARow := 1 to 50000 do 
  for i := 0 to AnotherForm.CheckListBox1.Items.Count-1 do
    if AnotherForm.CheckListBox1.Checked[i] then
       DoSomething(ARow,i);

Open in new window

0
Geert GOracle dbaCommented:
can't you use the OnInitEdit or OnInitEditValue of the view ?
this will only be executed for editing ... (you only edit 1 row at a time)
0
roknjohnAuthor Commented:
Geert,

The particular routine that I was refering to above, didnt't use any type of grid or database for that matter.  It is basically an import routine where only certain columns of an Excel spreadsheet are read into an internal data structure.  The columns to be imported were selected by the user using a TCheckedListBox on a popup dialog.  My input routine was referencing this TCheckedListBox repeatedly as the Excel file was traversed.  Evidently, the mere reference to the Checked[] property cause a HUGE spike in the dxBarWndProcHook calls.  I was able to overcome the performance loss by building a array of "checked" column indexes.  However, this fix was just for this particular routine in a 900K line application.  There are many more areas in the application that are now slower simply due to the use of the Express Bars suite.

I have provided the DevExpresss folks with a small sample project that demonstrates that by simply placing an ExpressBars tool bar on your form, causes a test routine to execute 35% slower.  I am waiting to hear back from them.

0
Geert GOracle dbaCommented:
one thing i found with devexpress ...
allways use
DataController.BeginUpdate;
try
  // do something with data

finally
  DataController.EndUpdate;
end;

this speeds up things a lot, and kills some bugs (funny behavior) too
0
roknjohnAuthor Commented:
You are correct.  I regularly use that in other projects, but this project has no data-aware controls at all, thus no DataController, no ADO, no TDataset, etc.  The only DevExpress control that I am using in this project is a toolbar component from the ExpressBars suite.

http://www.devexpress.com/issue=Q207335
http://www.devexpress.com/issue=B37633
0
Geert GOracle dbaCommented:
that's funny i have a huge app too in which i changed the sidebar to the devexpress suite.
didn't have any trouble,
besides having to alter the code, so i had a visible property for the buttons
0
Geert GOracle dbaCommented:
your first issue on devexpress is marked as private, so only you can see it .
0
roknjohnAuthor Commented:
Sorry, I forgot I had marked that as private. Here's a bit of the discussion:
Me:
I recently gave a mature project a facelift with the ExpressBars 6 suite from DevExpress. I changed out the menus and toolbars and the application looks much better (Office11 theme). Everything went pretty well until one of my users noticed that some operations took longer with the new version. I found this strange, since the code in question had not been altered, nor does it do any GUI stuff. For example, one action imports data from an Excel file. In the old version it took about 3.5 seconds. In the new version, it takes about 7 seconds.
I started investigating (thinking there must be some overhead threads) but have been puzzled. I wrote a test rountine that I call from the old source base and from the new source base. (Same code, same .dcu) The newer version is definitely slower.
Any ideas on how I can track down the offender? Both projects were compiled with Delphi 2007 (with optimization). Does ExpressBars use any background threads or anything that could be slowing things down?

Them:
Thank you for the question. Our ExpressBars Suite is a rather complex product and, generally speaking, it can have an influence on your application's performance. Unfortunately, it's very difficult to give you a precise answer...calling the Application.ProcessMessages method in your import function might slow down your application...
I've attached the profiling results that I sent to them.

ProfileResultsBeforeAndAfter.png
0
roknjohnAuthor Commented:
Also, here is the sample project file..  All file extensions have been changed to .txt for upload to EE.
SampleProject.zip
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Editors IDEs

From novice to tech pro — start learning today.