Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>"I've had been told [by whom?] that since .net linq is so slow [for what?] we shouldn't use it"</p> <p>In my experience, basing decisions such as what technique, library or language to use solely on what <em>someone</em> has <em>once</em> told you is a bad idea. </p> <p>First of all, does the information come from a source you trust? If not, you might be making a huge mistake trusting this (perhaps unknown) person to make your design decisions. Secondly, is this information still relevant today? But okay, based on your simple and not very realistic benchmark, you've concluded that LINQ is slower than manually performing the same operation. The natural question to ask yourself is this: is this code performance critical? Will the performance of this code be limited by <em>other</em> factors than the execution speed of my LINQ query -- think database queries, waiting on I/O, etc?</p> <p>Here's how I like to work:</p> <ol> <li>Identify the problem to be solved, and write the simplest feature-complete solution given the requirements and limitations you already know of</li> <li>Determine whether your implementation actually fulfills the requirements (is it fast enough? Is the resource consumption kept at an acceptable level?).</li> <li>If it does, you're done. If not, look for ways to optimize and refine your solution until it passes the test at #2. This is where you <em>may</em> need to consider giving up on something because it's too slow. Maybe. Chances are, though, that the bottleneck isn't where you expected it to be at all.</li> </ol> <p>To me, this simple method serves a single purpose: <strong>maximizing</strong> my productivity by <strong>minimizing</strong> the time I spend improving code that is already perfectly adequate. </p> <p>Yes, the day might come when you find that your original solution doesn't cut it any more. Or it might not. If it does, deal with it then and there. I suggest you avoid wasting your time trying to solve hypothetical (future) problems.</p>
    singulars
    1. This table or related slice is empty.
    1. POShould LINQ be avoided because it's slow?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USMartin Törnwall
    1. USMartin Törnwall
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COwell, first is isnt a recomendation, it is more of a dictated rule . If you can use a foreach rather than a linq statement then why not use it and not take the risk that you are doing a linq statement 10000 times since foreach could be considered less complex(not my words). I guess this thread is changing more into what is good programming practice and that tends to be more subjective. If you get 10 programmers in a room and ask their opintion, what would you get? 10 different opinions..... and a lot of arguing.. Im starting to sound a little cynical.
      singulars
      1. PO
      1. USuser455095
    2. CO@user: *"If you can use a `foreach` rather than a LINQ statement then why not use [the `foreach` statement] and not take the risk [...]?"* - my reason not to use the `foreach` statement is that the risk of a performance problem is vanishingly small when weighed against the risk that a bug will eventually be introduced due to awkwardly-written imperative code. It's easy to write a fast program that doesn't work. It's also harder to fix the fast-but-wrong program than it is to speed up the slow-but-correct program.
      singulars
      1. PO
      1. USAaronaught
    3. CO@user455095: I'm not aware of a "dictated rule" that says code should be written with execution speed as the primary point of consideration. There are certainly *specific* cases where execution speed should be favored over clarity and simplicity (think games, a chess engine, compression code, etc). In my experience, though, you'll greatly increase your chances of shipping a quality product by focusing on functionality rather than obsessing over speed. @Aaronaught: very well put -- you've nicely expressed the point I was trying to make.
      singulars
      1. PO
      1. USMartin Törnwall
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload