Novità di LINQ: è questo il posto giusto per utilizzare LINQ?

Question

Prima di tutto, sono nuovo di LINQ, quindi non conosco bene i dettagli. Sto tentando di usarlo in qualche codice al minuto, e secondo la mia diagnostica sembra essere veloce quanto usare un ciclo for allo stesso modo. Tuttavia, non sono sicuro di quanto sarebbe scalabile in quanto le liste con cui sto lavorando potrebbero aumentare in modo drammatico.

Sto usando LINQ come parte di una funzione di rilevamento collisione (che è ancora in lavorazione) e lo sto usando per selezionare l'elenco solo per quelli rilevanti per i controlli.

Ecco la versione LINQ:

partial class Actor { 
    public virtual bool checkActorsForCollision(Vector2 toCheck) { 
     Vector2 floored=new Vector2((int)toCheck.X, (int)toCheck.Y); 

     if(!causingCollision) // skip if this actor doesn't collide 
      return false; 

     foreach(
      Actor actor in 
      from a in GamePlay.actors 
      where a.causingCollision==true&&a.isAlive 
      select a 
      ) 
      if(// ignore offscreen collisions, we don't care about them 
       (actor.location.X>GamePlay.onScreenMinimum.X) 
       && 
       (actor.location.Y>GamePlay.onScreenMinimum.Y) 
       && 
       (actor.location.X<GamePlay.onScreenMaximum.X) 
       && 
       (actor.location.Y<GamePlay.onScreenMaximum.Y) 
       ) 
       if(actor!=this) { // ignore collisions with self 
        Vector2 actorfloor=new Vector2((int)actor.location.X, (int)actor.location.Y); 

        if((floored.X==actorfloor.X)&&(floored.Y==actorfloor.Y)) 
         return true; 
       } 

     return false; 
    } 
} 

Questo è il mio metodo precedente:

partial class Actor { 
    public virtual bool checkActorsForCollision(Vector2 toCheck) { 
     Vector2 floored=new Vector2((int)toCheck.X, (int)toCheck.Y); 

     if(!causingCollision) // skip if this actor doesn't collide 
      return false; 

     for(int i=0; i<GamePlay.actors.Count; i++) 
      if(// ignore offscreen collisions, we don't care about them 
       (GamePlay.actors[i].location.X>GamePlay.onScreenMinimum.X) 
       && 
       (GamePlay.actors[i].location.Y>GamePlay.onScreenMinimum.Y) 
       && 
       (GamePlay.actors[i].location.X<GamePlay.onScreenMaximum.X) 
       && 
       (GamePlay.actors[i].location.Y<GamePlay.onScreenMaximum.Y) 
       ) 
       if(// ignore collisions with self 
        (GamePlay.actors[i].isAlive) 
        && 
        (GamePlay.actors[i]!=this) 
        && 
        (GamePlay.actors[i].causingCollision) 
        ) { 
        Vector2 actorfloor= 
         new Vector2(
          (int)GamePlay.actors[i].location.X, 
          (int)GamePlay.actors[i].location.Y 
          ); 

        if((floored.X==actorfloor.X)&&(floored.Y==actorfloor.Y)) 
         return true; 
       } 

     return false; 
    } 
} 

Al minuto, sia eseguito in pochissimo tempo (ma eseguire numerose volte al secondo), ma man mano che il progetto si costruisce e diventa più complesso, questo si troverà ad affrontare molti più oggetti contemporaneamente e il codice per verificare le collisioni sarà più dettagliato.

Answer 1

Il tuo codice sembra abbastanza buono; Non sono un grande fan del cambiamento del codice di lavoro, ma se volessi riscriverlo per renderlo più facile da leggere, ecco cosa farei:

In primo luogo, astrarre il predicato "è fuori dallo schermo". Forse renderlo un metodo di GamePlay. Questo compito di verificare ogni volta se le coordinate sono nei limiti è (1) un dettaglio di implementazione e (2) rendere difficile la lettura del codice. È possibile che in futuro si disponga di un meccanismo più sofisticato per decidere se un oggetto è sullo schermo o meno.

In secondo luogo, allontanare l'operazione di pavimentazione vettoriale. Forse renderlo un metodo di Vector. Si noti che questo metodo dovrebbe restituire un nuovo vettore, non mutare il vettore esistente.

In terzo luogo, creare un operatore di uguaglianza sui vettori.

In quarto luogo, denominare il metodo migliore. Un predicato dovrebbe avere la forma "IsFoo" o "HasFoo". Lo hai formulato come un comando, non come una domanda.

In quinto luogo, non è necessario un ciclo.

In sesto luogo, è strano dire somebool == true. Dì solo somebool. Il primo significa "se è vero che questo bool è vero", che è inutilmente complicato.

Vediamo come questo scuote out:

public virtual bool HasCollisionWithAnyActor(Vector2 toCheck) 
{ 
    // "Easy out": if this actor does not cause collisions then 
    // we know that it is not colliding with any actor. 
    if (!causingCollision) 
     return false; 

    Vector2 floored = toCheck.Floor(); 

    var collidingActors = 
     from actor in GamePlay.actors 
     where actor != this 
     where actor.causingCollision 
     where actor.isAlive 
     where GamePlay.IsOnScreen(actor.location) 
     where actor.location.Floor() == floored 
     select actor; 

    return collidingActors.Any(); 
} 

Guardate quanto più facile che legge rispetto alla versione del metodo! Niente di tutto questo con le coordinate X e Y. Fai metodi di supporto per tutto ciò che riguarda lo scutwork. Il codice ora esprime chiaramente la semantica: dimmi se ci sono collisioni con altri attori viventi che causano collisione sullo schermo.

Answer 2

Qui la versione LINQ è più veloce della precedente perché si è dimenticato di creare una variabile locale per memorizzare GamePlay.actors[i]. Quindi, l'accesso all'array actors se eseguito un sacco di volte nel ciclo for.

public virtual bool checkActorsForCollision(Vector2 toCheck) 
{ 
    Vector2 floored = new Vector2((int) toCheck.X, (int) toCheck.Y); 

    if (!causingCollision) // skip if this actor doesn't collide 
    return false; 

    for (int i = 0; i < GamePlay.actors.Count; i++) 
    { 
     Actor actor = GamePlay.actors[i]; 
     // ignore offscreen collisions, we don't care about them 
     if ((actor.location.X > GamePlay.onScreenMinimum.X) && 
      (actor.location.Y > GamePlay.onScreenMinimum.Y) && 
      (actor.location.X < GamePlay.onScreenMaximum.X) && 
      (actor.location.Y < GamePlay.onScreenMaximum.Y)) 
     { 

      if ((actor.isAlive) && (actor != this) && 
       (actor.causingCollision)) // ignore collisions with self 
      { 
       Vector2 actorfloor = 
        new Vector2((int) actor.location.X, 
           (int) actor.location.Y); 
       if ((floored.X == actorfloor.X) && 
        (floored.Y == actorfloor.Y)) 
        return true; 
      } 
     } 
    } 
    return false; 
} 

Ora, LINQ come ottime prestazioni in generale. Ma ci sono alcuni casi in cui è meglio usare la classica versione for. Devi trovare il giusto equilibrio tra la compatibilità del tuo codice e le prestazioni (confrontando la versione LINQ e la versione for). Da parte mia, io uso e abuso di LINQ perché mi piace molto la sua sintassi e la sua flessibilità.

Ecco una versione completa LINQ:

return (from actor in GamePlay.actors 
     where actor.causingCollision && a.isAlive 
     where actor != this 
     where (actor.location.X > GamePlay.onScreenMinimum.X) && 
       (actor.location.Y > GamePlay.onScreenMinimum.Y) && 
       (actor.location.X < GamePlay.onScreenMaximum.X) && 
       (actor.location.Y < GamePlay.onScreenMaximum.Y) 
     select new Vector2((int)actor.location.X, 
          (int)actor.location.Y)).Any(actorfloor => (floored.X == actorfloor.X) && 
                    (floored.Y == actorfloor.Y)); 

Answer 3

non vedo alcun problema con l'utilizzo LINQ qui. Se volete sapere davvero se si stanno aumentando le prestazioni si dovrebbe fare qualche meassuring con Diagnostics.StopWatch

http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.elapsedticks.aspx

Inoltre, è possibile utilizzare ancora di più LINQ come questo per rendere la funzione un po 'più compatta.

return (from actor in (from a in GamePlay.actors 
            where a.CausingCollision == true && a.IsAlive 
            select a) 
        where (actor.location.X > GamePlay.onScreenMinimum.X) && (actor.location.Y > GamePlay.onScreenMinimum.Y) && (actor.location.X < GamePlay.onScreenMaximum.X) && (actor.location.Y < GamePlay.onScreenMaximum.Y) 
        where actor != this 
        select new Vector2((int) actor.location.X, (int) actor.location.Y)).Any(actorfloor => (floored.X == actorfloor.X) && (floored.Y == actorfloor.Y)); 

Answer 4

io non sono sicuro se ho capito la domanda, ma in generale penso che sia sempre una soluzione migliore per usare LINQ invece di creare ulteriori loop e if/else chiamate.

FYI: è anche possibile utilizzare il LINQ-Methodes invece delle parole-chiave, come:

foreach(Actor actor in from a in GamePlay.actors 
          where a.causingCollision == true 
          && a.isAlive 
          select a) 
{ 
    //... 
} 

è lo stesso:

foreach(Actor actor in GamePlay.actors.Where(a => a.causingCollision == true && a.isAlive)) 
{ 
    //... 
} 

il ritorno in entrambi i casi è un IEnumerable filtrato. La mia opinione personale è che i metodi sono più facili da leggere e capire. Nel campo Where (...) puoi inserire un'espressione lambda completa per selezionare completamente solo gli attori che desideri.

Answer 5

LINQ è abbastanza ottimizzato e il suo output è lo stesso della scrittura manuale dei file. A proposito, i metodi di estensione sono molto più leggibili. Il vostro esempio sarà simile a questa:

public virtual bool checkActorsForCollision(Vector2 toCheck) 
{ 
    Vector2 floored = new Vector2((int)toCheck.X, (int)toCheck.Y); 

    // skip if this actor doesn't collide 
    if (!causingCollision) 
    { 
     return false; 
    } 

    return GamePlay.actors.Where(actor =>  
      (actor.causingCollision == true) 
      && actor.isAlive 
      // ignore offscreen collisions, we don't care about them 
      && (actor.location.X > GamePlay.onScreenMinimum.X) 
      && (actor.location.Y > GamePlay.onScreenMinimum.Y)   
      && (actor.location.X < GamePlay.onScreenMaximum.X) 
      && (actor.location.Y < GamePlay.onScreenMaximum.Y) 
      // ignore collisions with self 
      && (actor != this)) 
     .Select(actor => new Vector2((int)actor.location.X, (int)actor.location.Y)) 
     .Any(actorFloor => 
      (floored.X == actorfloor.X) 
      && (floored.Y == actorfloor.Y)); 
} 

Non c'è alcun motivo per non usare LINQ per "motivi di prestazioni" se non si è profilata l'applicazione.