Epicor takes 25-30 sec to load the form. Example for Order Entry Form
Is there any way to increase the speed while loading the forms? As most forms are customized and personalized
Regards
Dnyanraj Patil
This should only happen the first time the form is loaded in a session. After that the form is cached and should pop up relatively quickly,
@Dnyanraj_Patil - Are you seeing this recently - in the last 3-5 days? Or has it been like this always? I’m having the same issue in the last 5 days - only with Order Entry. Bounced everything and no improvement - wondering if I’m the only one… 
And @josecgomez is right - the application caching should really improve this once the form is loaded on the client the first time. Subsequent ‘Clear Client Cache’ will reset this of course but it will re-cache every form the first time it’s loaded after clearing the cache.
Thanks for your feedback. 
@MikeGross: The user is facing this issue for the past 2 months for all the forms that are customized and personalized.
@josecgomez: Yes, It happens the first time the form is loaded in a session. I tried explaining the user but they want some solution to improve the performance.
I was thinking of a solution to move these customizations to external DLL’s. Since DLL’s are already compiled they might load faster.
Please let me know if this can work or any other solution will be appreciated.
Regard
Dnyanraj Patil
Are there two levels of caching?
The first being the first time a form is called during a session. During the first use in a session, local client files are compared to the files on the server, and updates are copied to the local machine as needed. That correct? Or are the local files always updated (whether they need it or not) with copies from the app server?
And once in a session, upon subsequent uses of the form, the files needed are pulled right from the client’s local copies without any checks. Correct?
The second being memory caching (an option available per each form). With this, after the first use in a session, the form stays resident in memory (for the duration of the session), for faster loading on subsequent uses. That right?
and what does the/SKIPCHECK command line option really do?
If performance is more important than Personalization to your user(s), you can turn that off (User Account Maintenance) for the users who complain the most and get nearly 50% improvement off the bat. If they can live without the customization, it will be wicked fast in comparison. 
Another alternative is to Memory Cache the form and hide the form start up cost in the login process. Needs to be turned off and on when customizations change though…
Also, on this customization of Order Entry, I get the “Downloading from DB” message everytime it launches in a session - except when I have Memory Caching enabled. And I never have memory caching enabled, because it annoys me when I go to customize a form, and forgot to disable that first.
Here’s a GIF of the form launching in the same session.
This is definitely not the solution
It adds un-necessary dependency and it won’t speed anything up
It will also add a nightmare at upgrade time.
Once a form has been cached unless you are doing active development on it it should load relatively quickly the cache only gets cleared if the user cleans it up or if the form changes significantly and a new copy is downloaded.
I wonder if there are scripts in place to clean the cache un-necessarely? I’ve seen some places do this because there are some issues with stale caching but obviously this leads to slower startup.
Frankly this is really a none issue, unless the user is closing Epicor all the way out every time they use it or use it sporadically they shouldn’t notice many performance issues once they’ve gotten going for the day.
You could trying completely clearing their cache related to Epicor if it has been happening for the last 2 months maybe there’s some corruption there. Manually delete / blow away the entire Epicor Cache structure in
C:\ProgramData\Epicor
This will make everything significantly slower the first time but maybe it will improve the overall situation.
Also this could be a problem of the PC or Workstation they are using being overloaded , not have enough resources or they are running a billion apps at once and are causing issues there.
Also do a network and latency check on their station again if there is high network jitter or dropped packages this could cause an overall sense of lack of performance as the Tcp stack struggles with re-tries to get the information across.
Also Check the Custom XML when you open the Script Editor do Tools -> Custom XML Editor
Folks often dont realize, as you click or make columns hidden/visible on GRIDs Epicor is recording everything as a Customization… You may have accidently moved 20 items 1px (just to view their properties) and Epicor stored it as a “Customization”.
Rule of Thumb always clean up Custom XML when you are done, stuff will sneak into there… Even your personal “Form Options” and before you know it, your XML is 7mb large.
The largest cost is always customizing a Grid… you think you want to make 1 column change… Epicor records the entire GRID as a Customization, which immediately can add 1MB, depending on column count.
Calvin, you’re not crazy. Well, at least this isn’t proof. Since 10.2.400, we saw this but I thought it was a SaaS thing. Not just at every login, but anytime you closed the form and went back into it.
My local cache (C:\ProgramData\Epicor\xxxx-808\3.2.300.0\MC\CustomDLLs) seems to keep several copies…
In this first screenshot, the most recent file (newest date) doesn’t have a suffix (like ..Code.7.dll
But after closing the form (leaving the session open) and relaunching, I now see that the “un-suffixed” file is not the most recent.
Did it download a “newer” version(.0 and .1), but keep using the un-suffixed file?
If and when you go in in Customization / Developer mode it downloads a new .XX suffix and uses that.
If and when you go in as a regular user it uses the CustomCode.dll
This is my guess based on my observation of the behavior.
Not what happens on my system.
On my client:
Clear out folder C:\ProgramData\Epicor\usdcaaps00371-808\3.2.300.0\MC\CustomDLLs
No files in folder
Launch E10
After client launches just one file (personalization of SysMonitorForm)
Launch Order Entry (customization SOE_07), not in developer mode
After SOE_07 loads, 2 new files
App.SalesOrderEntry.SalesOrderForm.EP.MC.Customization.SOE_07.CustomCode.dll
App.SalesOrderEntry.SalesOrderForm.EP.MC.Personalization.SOE_07.manager.CustomCode.dll
Closed SOE_07
Client CustomDLLs folder remains unchanged
Launch SOE_07 again (still not in developer mode)
Two more files now appear in CustomDLLs folder
App.SalesOrderEntry.SalesOrderForm.EP.MC.Customization.SOE_07.CustomCode.0.dll
App.SalesOrderEntry.SalesOrderForm.EP.MC.Personalization.SOE_07.manager.CustomCode.0.dll
Note the added .0. to the file names
These two new files have the more recent file date
Strange.
I just tried the same steps @ckrusen, and I didn’t get any .0. files…
I’m on 10.2.500.17 though. Looking through the list of files before I cleared them out, I do see some that go all the way up to .7.
I wonder what triggers the revisions. Do you switch between production/test/demo any?
My test was entirely done in Test environment (but to be clear both Prod and Test use the same folders in c:\ProgramData\...)
I’m not seeing it when i do it in my Prod environment. The custom DLL gets copied to the CustomDLLs folder, but doesn’t add any “revision” suffix.
