You should submit a support case with a video recording (not the whole 20 mins, but maybe a smaller example). You may have found something that we had not seen before. The browser, for the most part is faster. There are a few places where it is the same, but you should not find something like this where it it takes 4 times as long.
Is there a size limitation? When I first starting testing and building the functions it was fine. But it was tiny. Once I built everything is when it really slowed down.
I have well over 100 inputs which… idk if that is normal and people typically run smaller configurators?
I’ve worked with configurators in Browser that have well over 100 inputs, and they run pretty quickly. Are there a lot of rules on your inputs that update other fields?
Well.. that depends on what you are doing. Again the configurator is a programming language that you are controlling… it really depends on what you are doing inside that configurator. One benefit of submitting a case is that you can also export your configurator, and our dev team can take a look to see what might be going on as far as efficiency is concerned. We have a “tiger team” that is focused on product configurator performance to help resolve issues such as this.
Some options require other options and some options wont work with each other… so there are read only statements and etc that modify drop downs and etc.
Doing some more testing and it appears to only be slowing way down when it has to pull a price from my UDtable. Epicare suppport said this is a known issue and they are working on it. I guess we shall see what they come up with.