Slow performance compared to “pure” react-native

[vasafix]

Describe the bug I Wrote 2 lists, one using native-base components, second one using react-native components, and I am experiencing 2 to 3 times slower render on native-base side, my example consists of fairly simple list, so I wanted to ask if anyone else is experiencing similar performance issues, or for advice on what am I doing wrong or how to speed things up.

To Reproduce In my example are 2 buttons, which will navigate you to respective list, with time it took to fully transition in ms.

Expected behaviour Similar render times to react-native components.

CodeSandBox/Snack link codesandbox template

Render times in ms

	DEV	DEV	DEV	DEV	PROD	PROD	PROD	PROD
Native Base	Android	Android	IOS	IOS	Android	Android	IOS	IOS
	Emulator	Samsung S21	Emulator	Iphone 13 Pro	Emulator	Samsung S21	Emulator	Iphone 13 Pro
1	1103	319	266	188	605	255	208	150
2	947	303	173	199	522	232	101	149
3	966	339	163	191	615	236	94	150
4	1069	306	157	191	496	211	101	150
5	919	307	154	192	543	209	90	150
Avg.	1000,8	314,8	182,6	192,2	556,2	228,6	118,8	149,8
	DEV	DEV	DEV	DEV	PROD	PROD	PROD	PROD
React Native	Android	Android	IOS	IOS	Android	Android	IOS	IOS
	Emulator	Samsung S21	Emulator	Iphone 13 Pro	Emulator	Samsung S21	Emulator	Iphone 13 Pro
1	424	104	93	89	111	32	27	47
2	395	105	62	91	96	39	24	46
3	437	106	64	90	101	38	24	45
4	472	135	63	91	89	39	22	44
5	528	103	63	90	87	40	27	44
Avg.	451,2	110,6	69	90,2	96,8	37,6	24,8	45,2

[ezze]

@vasafix Does it happen with any 3.x version?

I am experiencing an issue with 3.0.6 in Android: the more Native Base components are rendered the slower further rendering performance (i.e. when switching between visible app components). Each time I create and render a component including Native Base components I see more visible delays before my component starts to interact (run useEffect callback on mount). Seems like something is blocking event loop.

I don't see any performance issues if I switch to React Native components.

I thought that these issues might be related.

[md-rehman]

@vasafix have you tried our latest release because we have done a lot to fix these kinds of performance issues.

So @vasafix and @ezze, I would highly recommend both of you share your feedback on the performance of our latest version (i.e., 3.3.2).

[ezze]

@MD-REHMAN My issue is resolved after upgrading to 3.2.2. Unfortunately, I can't upgrade to 3.3.x at the moment because it introduces new bugs like this.

[vasafix]

@MD-REHMAN Can’t compare, because after updating to 3.2.2. I am now getting error:

useTheme must be used within NativeBaseConfigProvider

New snack link (native-base-3.3.2) This example is exactly same as the original one I posted, with difference of native-base version and its new dependencies @types/react and @types/react-native

[vasafix]

@MD-REHMAN Can’t compare, because after updating to 3.2.2. I am now getting error:

useTheme must be used within NativeBaseConfigProvider

New snack link (native-base-3.3.2) This example is exactly same as the original one I posted, with difference of native-base version and its new dependencies @types/react and @types/react-native

Seems that 3.2.4 fixed this error, I will make new render time table

[fatshotty]

Hi @vasafix did you try with a new render time table? I upgraded nativebase to latest version ( 3.3.7 ) but low-performance problem is still there

thanks in advance

[qlereboursBS]

My company and I also have performance issues A simple test can be done like this:

const TestComponent = () => {
   const [data, setData] = useState(0);
   useEffect(() => {
       const interval = setInterval(() => setData(d => d+1), 100);
       return () => clearInterval(interval);
   }, [])

   return (
       <>
           <Text>{data}</Text>
           <Button onPress={() => console.log(data)}>Click me!</Button>
       </>
   )
}

It simply rerenders every 100ms. When importing Button and Text from NativeBase, there's a latence on the button (like a few seconds), but when importing from ReactNative, or other libs like MagnusUI, there's no (or a few ms) latence. This is a stress test, but you will have the same issue with 1s rerender frequence. It's an issue which should be high priority, because it prevents to use NativeBase as a component library.

I think a good first step would be to check which component has to be optimized, to understand if it's the whole library (because of the contexts?, or the way props are computed?) or only a few components

[pierroo]

Unfortunately I also have to step in and confirm that as of today nativebase just isn't viable in production for android devices. I am currently undergoing the process of rewriting my whole app (which is live and distributed to millions of users...) using simple react native component; what a bummer.

If there is any plan on improving performance for android I would love to hear about it.

[Wei102193]

I posted a similar issue on This. I believe the more React Native components you use the slower your app will be. Native Base is great. But this is a big issue. Most people will get rid of Native Base from their code because of it. And it is too sad that they have to rewrite their project in pure react-native if their code heavily depends on it. So read this before you dive deeply into native base. Hope they can fix this issue soon.

[arunim2405]

https://snack.expo.dev/H3aB8nOYG The lag is still there and it is still significant. I have discovered this issue right before pre-production testing and I have no idea how I am going to replace these many components.

[tankers746]

After doing some profiling the issue seems to lie with with this function which is called on every render of every component https://github.com/GeekyAnts/NativeBase/blob/74274d3b6bbaa49cf3731afb58027c4f8d5c22bb/src/hooks/useThemeProps/usePropsResolution.tsx#L193

Ideally this could be refactored to reduce the new object allocation.

[rayan1810]

Hey folks, performance is on the top of our priority list right now, we wanted to stabilize a few things before jumping on this ship hence the delay, but be assured NativeBase will have the performance issues sorted in the upcoming weeks.

[seeden]

Benchmarks: https://tamagui.dev/docs/intro/benchmarks

[thirteenthstep]

Those benchmarks are actually quite shocking. I can confirm performance problems when navigating to new screens, where users experience a significant delay while the new screen is being rendered.

[rayan1810]

The tamagui benchmark results are quite old, If I remember correctly these results were out when NativeBase v3 was initially released. But since then it has already improved significantly but yeah much more work is needed and we are already on it ✊ .

[ababol]

I can confirm we also have huge lag issue on Android using native-base.

Especially on list, we have to really be careful on changing a state/re-rendering list, we try not to in Android. We had to disable some feature on our app because of that.

[pierroo]

I can confirm we also have huge lag issue on Android using native-base.

Especially on list, we have to really be careful on changing a state/re-rendering list, we try not to in Android. We had to disable some feature on our app because of that.

Make sure to use pure/memoized component like you mentioned, but not only: when inside a list, I make sure the renderItem does not render native base component, I go back to pure react native Views and it does fix the list performance issue.

Of course this is just some temporary "hack" while waiting for native base to fix those performance issues...

[ababol]

@pierroo Yes, thanks a lot for the recommendation, but in our case we cannot really afford that, one of the main component of our app EventCard is written using native-base in order for us to have it working on both the app and the web, that's actually one of the main reason why we choose native-base

Rewriting this component in pure react native would probably help a lot with the performance issue (thanks a lot for the suggestion), but it would also be like dropping native-base and its benefit/why we choose it :(

[foyarash]

Hello

We had the same performance issues as described in the previous comments. The issue was mostly visible on Android, but also on iOS.

We did a workaround requiring some work, but allowing us to keep a majority of native base props, by using the useStyledSystemPropsResolver hook, which is not impacted by any performance issue. By doing that we saw an improvement of more than 50% for the first render time of our most impacted screens.

Here is an example implementation for the Box component:

const Box = forwardRef<View, React.PropsWithChildren<BoxProps>>(
  ({ children, _text, safeAreaBottom, safeAreaTop, ...props }: React.PropsWithChildren<BoxProps>, ref) => {
    const [style, otherProps] = useStyledSystemPropsResolver(props);
    const { top, bottom } = useSafeAreaInsets();
    const safeAreaStyle = useMemo<StyleProp<ViewStyle>>(() => {
      const baseStyle: StyleProp<ViewStyle> = {};
      if (safeAreaBottom) {
        baseStyle.paddingBottom = bottom;
      }

      if (safeAreaTop) {
        baseStyle.paddingTop = top;
      }

      return baseStyle;
    }, [safeAreaBottom, safeAreaTop, top, bottom]);

    return (
      <View {...otherProps} style={[style, safeAreaStyle]} ref={ref}>
        {wrapStringChild(children, _text)}
      </View>
    );
  }
);

Where View is imported from react-native.

For the rest of the component, the goal was to also mimic how native-base would interact with the theme, for example for the Pressable or the Button component.

Hope this will help.

[arryanggaputra]

@foyarash very impressive 🔥. Have you managed to fix the Button performance issue? Can we know your implementation?

[foyarash]

@foyarash very impressive 🔥. Have you managed to fix the Button performance issue? Can we know your implementation?

I made a gist with the few files i used https://gist.github.com/foyarash/fa260a37fae9b085b89af13f61f46713

This worked well in our case since we don't have to handle dark mode for our app, so keep in mind that it really depends of the features you're using with native base.

[antoinerousseau]

@rayan1810 any progress on this? Do you need any help? If we can assist or support let us know :)

[iooi]

+1. I feel the lag on iOS while using NB for a couple of weeks. Really need to re-think if i need to abandon it. I am a paid customer.

[frossi85]

While the issue described here is regarding Mobile, I am experiencing a similar issue using native base with NextJS. The biggest issue is observed on inputs that use text like Input and TextArea. Writing fast on the input does not provide instant feedback but takes a while between typing fast and seeing what was typed reflected in those inputs. Also, there are some slow animations. So I guess the issues are in the core and not the platform-specific implementation.

Does the team have a deadline? I am asking because started to implement something that needs to go to prod in 2 months but if the issue remains I will need to replace Nativebase.

[rayan1810]

Hey folks, we are currently working on it and have already fixed components like Checkbox, we have found that the major performance issue is on Android. Currently, we are trying to resolve component theme props at boot time and inline props at runtime. I guess this will reduce the overhead on the JS Engine during runtime and give a perf boost to the App.

[rayan1810]

Also for the perf issues on other Platforms apart from Android, It would be really helpful if you guys can share some code snippets and GIFs of the same.

[pierroo]

Hey folks, we are currently working on it and have already fixed components like Checkbox, we have found that the major performance issue is on Android. Currently, we are trying to resolve component theme props at boot time and inline props at runtime. I guess this will reduce the overhead on the JS Engine during runtime and give a perf boost to the App.

Thank you for your reply and information. Having fixed Checkbox is great for sure, but considering the hundreds of other components that needs to be fixed as well, is there any way to follow up the progress or have some kind of roadmap to better align our expectations?

Somehow, there must be some issue in the core of native base and its way of writing components, that once found out and fixed should be easily replicated overall, no?

Not gonna spoil this thread, but another easy way to see how slow the overall components are, switching from day to night mode in the app takes around 2-3 seconds, where it happens almost instantly with any other provider. Maybe this will be improved with your current work on boosting runtime?

[rayan1810]

Hey @pierroo we did some experiments today, with the above mentioned idea and were able to achieve 3x better results with simple component theme resolutions. Like when you try rendering 100 Boxes with some bg and height, width it used to take ~24-26ms but now we were able to reduce it to just 8-9ms. Now we are planing to implement it properly and handle states like hover, focus, checked and so on. This is actually the most tricky part. Will try to keep you guys in loop. Also any suggestions are welcome.

PS: This makes switching color mode almost instant.

[arryanggaputra]

I also try to change lodash implemenation inside NativeBase with JavaScript native implementation. I got this result

[arryanggaputra]

Hi @rayan1810 , just curious... Is there any plan or update for this issue?