This is great tool, but unfortunately on our bigger project is nearly unusable.
We have 1700 resource keys in approximately 100 resource files.
When I open ResxManager, visual studio hang to nearly 10 seconds.
Next action unselect all resources, hang next 10 seconds. Practicaly every change selection do this hang.
When I try scroll resources and some name are too long. The ResXManager change layout to show full name, but hang another 5 seconds before change layout.
I profile this preformance issue and attach results .
Results was measured during this sequention actions:
- unselect ALL resources
- select ALL resources
- Scroll from start to end resources
- Scroll from start to end resources
In attachments are unrolled two biggest method.
Thanks .
Comments: ** Comment from web user: jbalarin **
"The ProcessMessages that you see in the profiling actually does nothing, it just yields control to the UI so it will do incremental updates - which makes it feel going faster. If I remove this call, the total time for populating the grid is the same... "
=>
Actualy, I try comment "ShellViewModel.cs" whole method "SelectedEntities_CollectionChanged" and populate/repopulate whole grid increase nearly 2x (4s -> 2.2s). Its to big overhead, maybe call it not every collection change, but every 20 or 50 will by enought.
"I'm testing large projects with the standalone version, selecting the root of several solutions with gives me about 500 projects with 15,000 entries in 30 language. This takes about 5sec to populate the whole grid, which seems to be acceptable for such an amount of data."
=>
Did you profile your project speed ? I guest the 5s isn't searching and parse resourcefiles, in my case this was neglible, something between 5-10%. If we exclude this. In your case its 4.5s for 15000 entries. Which is 3333.33 per sec. Lets say CPU running at 2Ghz (my working at 1,5Ghz, but its not a point) so we have 600 000 cpu tick for add one entry. Its too much for basic add entry and show in grid, even for WPF. Resonable value would by 10 times lower. Something is somewhere doing ineffectively.
"WPF does not have a "repaint"
=>
I know the WPF working a little different, but still I think the victim is call to much NotifyCollectionChange.
For example from my profiling:
in
TomsToolbox.ObservableCollections.ObservableWrappedCollection.OnSourceCollectionChanged(IEnumerable, NotifyCollectionChangedEventArgs)
- case NotifyCollectionChangedAction.Remove may call removeAt more then one time. Every call removeAt invoke subsequent oncollectionchange. If it would by changed to some remove range, oncollectionchange would by call only onetimes with same affect. :)