long waiting times for binder.writeBean(bean)

I have a Detail-View where the user can configure an object Foo using many Input Components distributed in 7 Tabs. The Binder<Foo> in use has 67 bound fields in total; mostly TextFields for String values, TextFields with a custom StringToNumberConverter for numerical values, and ComboBoxes for enum values. None of the field bindings have validators, and I have not added any bean-level validation either.

When the save button is pressed, The user has to wait a surreal amount of time, so I measured the time used by the method binder.writeBean(foo); - it takes 74 seconds.

Is it normal that this takes that long? Are there ways to reduce this waiting time considerably? Am I using Binder wrong?

Hi Kaspar. I’ve yet to hear anything of such performance issues, even though 67 fields is a lot and those probably should not be attached to the UI unless needed (e.g. the corresponding tab is opened), it still should not take 74 seconds. So sounds like something is going wrong.

Please create a minimal reproducable code example and submit an issue to https://github.com/vaadin/flow/issues so it can be investigated further.

Hi Pekka

Thank you for your answer. I refactored my Detail-View into smaller views for each of the tabs just like you suggested. The View with the most bound fields (24 bound fields) now takes ~20 seconds for binder.writeBean() (I could not do exact measures because I need to rewrite my UI tests now). The View with the least bound fields (1 bound field) takes less than 1 second.

While this is already much better than before, I still wish to reduce the waiting time further.
I will try to create a minimal reproducable code example to submit an issue this week.

Hi Pekka

I found the culprit myself. Gladly will I share what I found. The fault was 100% caused by me.


As stated in my original post, I use TextField components for numerical value inputs and use custom StringToNumberConverters (in order to apply a specific NumberFormat which does not match my locale).
Initially used for a Vaadin 8 Application, these custom converters still had a very strange workaround in them: Sleeping the Thread for 1 second in the method convertToModel.

@Override
public Result<Double> convertToModel(String value, ValueContext context) {
	// delay the Inputfield-conversion to model with a thread.sleep.
	// This is done to allow slower user inputs without converting them too hastily (insertion point will be reset, very user unfriendly)
	// basically fake a debounce of 1000 ms
	try {
		Thread.sleep(1000);
	} catch (InterruptedException e) {
		LOGGER.error(e.getMessage(), e);
	}

	//... actual converting here ...
}

I remember that I did this because there was a strange debounce issue; while typing in the number, the number was immediately debounced and converted which led to the cursor going to the right and most importantly mess with the custom NumberFormat. It was a strange workaround and should have been solved better by us.

I now removed the call to Thread.sleep, and the debounce issue seems to be gone. It also makes my binder.writeBean() method fast again. yayy :slight_smile:

I have just two fields and it takes 5 sec. It’s a performance issue.

Imran Momin:
I have just two fields and it takes 5 sec. It’s a performance issue.

5 seconds sounds like too much, yes. Please create a minimal reproducible code example and submit an issue to [flow GitHub]
(https://github.com/vaadin/flow/issues).