Welcome back! Today we’re going to compare the Turbo Extract DataRaptor with its “naturally aspired” counterpart. Managers and Architects are often using harsh language on developers that are not using those on every occasion. And it makes sense, as according to documentation, DataRaptor Turbo Extract has simpler configuration and better runtime performance.

So, let’s take look at the numbers and see how much faster the Turbo Extract really is.

Test Setup

For testing the performance, we’ve created a simple object with 4 custom fields:

The object was loaded with 1K sample generated records.

We’ve then created a regular and a Turbo Extract DataRaptors to extract the data from it:

Regular Extract DataRaptor

Turbo Extract DataRaptor

We will compare them on indexed and non-indexed fields using our sample object.

Now OmniStudio caches the results to improve performance of subsequent queries when parameters are the same, so we will also look at the cached vs un-cached requests in terms of performance.

The following table shows the timings when using an indexed field (ID):

	Without caching			With cache
	DataRaptor Extract	DataRaptor Turbo Extract	Difference	DataRaptor Extract	DataRaptor Turbo Extract	Difference
Browser Time	1209 ms	1069 ms	13%	1020 ms	917 ms	11%
Server Time	465 ms	416 ms	12%	384 ms	300 ms	28%
Apex CPU	348 ms	281 ms	24%	280 ms	243 ms	15%

Wow! That’s not the kind of difference I was hoping for! The Turbo Extract is faster than its non-turbo counterpart, no surprise there. But the fact that even when we look at the pair of metrics that are the furthest apart – we’re still looking at less than 30% improvement!

Now, let’s modify our DataRaptors to use the non-indexed field for extraction:

Again, the table below shows the timings of running the Turbo and Regular extract DataRaptors – with and without caching on a non-indexed field (Index__c):

	Without caching			With cache
	DataRaptor Extract	DataRaptor Turbo Extract	Difference	DataRaptor Extract	DataRaptor Turbo Extract	Difference
Browser Time	972 ms	967 ms	0.5%	870 ms	815 ms	7%
Server Time	411 ms	334 ms	23%	374 ms	296 ms	26%
Apex CPU	298 ms	261 ms	14%	310 ms	252 ms	23%

And again, results are about the same – less than 30% improvement across the board!

Testing the DataRaptors from inside an IP produces similar results:

Regular DataRaptor Extract:

Turbo Extract DataRaptor

Taking it further

DataRaptor Turbo Extract supports querying one object at a time. So, if we want to query multiple objects – we would have to use a few Turbo Extracts to do that. And this is exactly what many developers are doing now, in hopes of reaping the benefits of the “turbo-charged” performance.

In the following test, we will compare the performance of two DataRaptor Turbo Extracts run sequentially – against a single traditional DataRaptor Extract running the same queries in a single call.

Let the best Raptor win!

Regular DataRaptor Extract with two queries:

And here’s the timing when measured from the IP:

Turbo Extract DataRaptors 1 and 2, performing the same queries:

Performance when measured from IP:

Turbo Extract DataRaptor 2:

And its performance as seen from the IP:

There’s no surprise there – results are consistent with what we’ve seen before. While each Turbo Extract DataRaptor is a little bit faster, running two queries in two separate Turbo Extract DataRaptors is almost two times slower than running both queries in one non-turbo, traditional DataRaptor.

In this article we have compared the DataRaptor Turbo Extract with regular DataRaptor Extract in terms of performance. We have received specific numbers and now can estimate how much of an improvement we may be able to expect out of using the Turbo Extract DataRaptor instead of the regular Extract. We have also seen that replacing one regular DataRaptor Extract running on multiple objects with two or more separate DataRaptor Turbo Extracts resulted in an inferior performance. This is the valuable information that may come in handy when deciding what kind of DataRaptor we should be using in our specific application scenarios.

As you’ve just seen, applying a best practice may not always bring the performance improvement you expect. You may want to test the performance impact of the best practices in your specific scenario before making changes to your app. We at ECM Solutions have done a lot of testing and can help you narrow down the possible solutions quickly, based on what we ourselves have proven accurate and effective for clients in similar situations. Talk to us to see if we may be a fit to help with your current or future project.

Lastly, if you think this information may benefit your project or your career, be sure to subscribe to my low-traffic notification list in the box in the right column. These OmniStudio best practices and performance tips take time to verify, so they are not released often. And you don’t want to miss them as they may easily take you to the next level just at the right time. Also, we never share your email with anyone, and you can always unsubscribe with one click.