Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / August 2007

Tip: Looking for answers? Try searching our database.

ceative suggestions wanted

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
nlbauers - 10 Aug 2007 17:27 GMT
Hi all,

I am looking for suggestions for replacing a very large 2D double
array in my application with some kind of out of RAM storage.   The
data stored in the array will soon be growing so large that it will
impact application performance by sucking up most of the system RAM.
We expect the existing design will soon require an array of over 800MB
of space and future requirements will need even more.  The big issue
we have is access time-  the solution should minimize impact on the
application execution.  Currently the array is written to once at
application startup, it is then read on a single element basis
(meaning elements are picked out here and there, not looping over
large portions of the array) fairly often during normal application
execution, and the values are updated infrequently.  That means that
single element access is the thing we are the most concerned about
dragging down application performance.  So, here are the current
suggestions:

1) Replace the in-memory array with a database.  The plus side here is
that in-memory size wont be an issue.   The down side here, is that
accessing single records/elements (a fairly common operation) would be
an order or magnitude more expensive.  My testing indicates 500x
slower to access a single database record.

2) Replace the in-memory array with a binary file.  My testing
indicates that single element file access would be slightly faster
than a database query, but still an order of magnitude slower than in-
memory array access.

3) A buffered hybrid storing the most commonly accessed elements in-
memory and paying the performance penalty when retrieving those that
are not used as often.  This is the solution we are leaning toward.

Anyone else have a clever suggestion for solving this problem?  Seems
to me this problem must have been solved before.

The solution will be implemented in C# or C++ if it matters.

Neil
Peter Bromberg [C# MVP] - 10 Aug 2007 18:52 GMT
Take a look at Memory Mapped files. If you search around, you should be able
to find several implementations in managed code with P/Invoke.
-- Peter
Recursion: see Recursion
site:  http://www.eggheadcafe.com
unBlog:  http://petesbloggerama.blogspot.com
BlogMetaFinder:    http://www.blogmetafinder.com

> Hi all,
>
[quoted text clipped - 35 lines]
>
> Neil
Ignacio Machin ( .NET/ C# MVP ) - 10 Aug 2007 19:35 GMT
Hi,

> Hi all,

> 1) Replace the in-memory array with a database.  The plus side here is
> that in-memory size wont be an issue.   The down side here, is that
> accessing single records/elements (a fairly common operation) would be
> an order or magnitude more expensive.  My testing indicates 500x
> slower to access a single database record.

You can cache part of the data you work with

Additionally you could simply move the processing to the DB, in SQL 05 you
can move .NET code to the DB itself.
nlbauers - 11 Aug 2007 01:27 GMT
Thank you very much for the suggestions.  It looks like Memory Mapped
files are going to work for us.

Neil

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.