Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 18 | Comments: 82

filter by tags archive

Performance implications of method signatures

time to read 2 min | 289 words

In my previous post, I asked: What are the performance implications of the two options?

image_thumb

Versus:

image_thumb1

And the answer is quite simple. The chance to optimize how it works.

In the first example, we have to return an unknown amount of information. In the second example, we know how much data we need to return. That means that we can optimize ourselves based on that.

What do I mean by that?

Look at the method signatures, those requires us to scan a secondary index, and get the results back. From there, we need to get back to the actual data. If we knew what the size of the data that we need to return is, we could fetch just the locations from the index, then optimize our disk access pattern to take advantage of sequential reads.

In the first example, we have to assume that every read is the last read. Callers may request one item, or 25 or 713, so we don’t really have a way to optimize things. The moment that we have the amount that the caller wants, things change.

We can scan the index to get just actual position of the document on disk, and then load the documents from the disk based on the optimal access pattern in terms of disk access. It is a very small change, but it allowed us to make a big optimization.


Comments

Lee Atkinson

May I suggest that the original question was not clear - you asked what the implications for the methods, but the answer is about the implications for implementing those methods.

Poul Foged

IMO. This is why IQueryable was invented; Lets the callee see the intentions of the the caller ...

Bart

I also do not understand why you aren't going with an IQueryable approach. Can you explain why?

Kristof Claes

Poul Foged: As Mark Seemann states in his blogpost (http://blog.ploeh.dk/2012/03/26/IQueryableIsTightCoupling.aspx), this is not always a good idea.

gandjustas

If IQueryable is too heavy solution, then you can inplement your own ResultSet type and Linq extension methods.

Johannes Gustafsson

I believe the point is to force the user to decide how much data it wants. IQueryable won't help there.

gandjustas

Why user should decide it? What if I want just "default" number of results?

Moreover this repository-like interface is too restrictive. How can I get documents after eTag starting with some prefix?

Rafal

So, did you just prove that having more information is better than having less?

Jonathan Allen

I still don't understand. If you are streaming data, just get the first batch and wait until they have consumed enough the trigger the next batch. You don't need to know how many batches will be fetched in total since you are only reading them on demand.

If you are not streaming data, then you shouldn't be using IEnumerable.

Pop Catalin

"In the first example, we have to assume that every read is the last read"

That doesn't sound right to me.

Generally when working with a rotating disks (but not limited to), you generally prefetch and use buffers in order to avoid disk seeks, even if this means fetching more data than necesary.

What's the basis for aforementioned assumtion?

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. The insidious cost of allocations - 16 hours from now
  2. Buffer allocation strategies: A possible solution - 4 days from now
  3. Buffer allocation strategies: Explaining the solution - 5 days from now
  4. Buffer allocation strategies: Bad usage patterns - 6 days from now
  5. The useless text book algorithms - 7 days from now

And 1 more posts are pending...

There are posts all the way to Sep 11, 2015

RECENT SERIES

  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    03 Sep 2015 - The industry at large
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats