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# / March 2008

Tip: Looking for answers? Try searching our database.

Quickly Finding Items by multiple indicies

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
jehugaleahsa@gmail.com - 25 Mar 2008 15:32 GMT
Hello:

This is probably more of an algorithms question than a C# question.

We have these classes that represent lines on a report. They contain
two field:

1) Line Print - A String that indicates the type of line and ordered
lexicographically.
2) ModCode - A String that indicates that a special action should be
taken on the line.

Since Line Print is the order that the lines are calculated and
displayed, I have a List<Line> sorted by Line Print. However, the
existing code commonly searches for all lines with a given mod code.
To do this, however, requires a linear search.

I can use binary search to find a line print, no problem. However, I
want to eliminate the common occurence of linear searches for multiple
mod codes.

First of all, is it a bad to have all these linear searches? Supposing
it is, what is the overhead of storing the Lines in both a List and a
Dictionary<string, List<Line>> going to mean for performance?
Performance does matter, here. Sure, my search times would decrease,
but I am afraid the extra memory could be problematic as well.

Suggestions?
Lasse Vågsæther Karlsen - 25 Mar 2008 15:54 GMT
<snip>
> First of all, is it a bad to have all these linear searches? Supposing
> it is, what is the overhead of storing the Lines in both a List and a
[quoted text clipped - 3 lines]
>
> Suggestions?

At the moment, do you have any problems running this code against a
large dataset, like takes too long, etc.?

If not, I wouldn't prematurely optimize something that works, just
because you feel something could be done with it.

If you can justify the time taken to optimize the code against the time
needed to retest and recertify the code, the increased potential for
bugs, then it could be worth it.

Signature

Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3

jehugaleahsa@gmail.com - 25 Mar 2008 17:23 GMT
> jehugalea...@gmail.com wrote:
>
[quoted text clipped - 22 lines]
> mailto:la...@vkarlsen.nohttp://presentationmode.blogspot.com/
> PGP KeyID: 0xBCDEA2E3

There is a N^3 operation that occurs for every line. This line will
appear 744 times (for every hour of the month). This is run almost 200
times for our customers. Saving a milliseconds quickly cuts minutes
off runtime.

I will obviously test the outcome. I was only wondering, if it becomes
requirement, whether I would have to do a lot in terms of data
structures.
Jon Skeet [C# MVP] - 25 Mar 2008 17:36 GMT
On Mar 25, 4:23 pm, "jehugalea...@gmail.com" <jehugalea...@gmail.com>
wrote:

<snip>

> There is a N^3 operation that occurs for every line.

At what point though? During searching? If not, changing searching
isn't going to change much.

It's still not clear what your dataset size is. Is it 200*744? If so,
a linear search of that will be *slightly* painful, but still not
hugely bad.

The overhead of a dictionary isn't likely to be particularly nasty in
terms of memory, but obviously it will be present.

Jon

Rate this thread:







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.