Lettura dei nomi degli elementi rispetto agli attributi degli elementi di lettura: velocità

Question

Lettura dei nomi degli elementi rispetto agli attributi degli elementi di lettura: velocità

#1 da (5 voti)
#2 da (0 voti)

1

Sto lavorando a un progetto in cui sono state memorizzate molte stringhe in un file XML per il successivo recupero. Stored con ogni stringa sono tra 0-10 tag che un utente può utilizzare per accedere e ordinare queste stringhe.

Il caso d'uso generale a cui sto lavorando è l'inserimento di un tag "per trovare" e l'app che utilizza la funzionalità XMLREADER per l'esecuzione e l'identificazione di tutte quelle stringhe con tag corrispondenti.

La mia domanda : mentre progetto lo schema XML, ci sono delle differenze prestazionali note tra la lettura del nome di un elemento e il suo attributo? Ad esempio se progetto il mio schema in questo modo:

<requirement>
  <string>Here is the string text</string>
  <tags>
    <tag id='technology' />
    <tag id='users' />
  </tags>
</requirement>

vs

<requirement>
  <string>Here is the string text</string>
  <tags>
    <technology />
    <users />
  </tags>
</requirement>

E sto analizzando cercando tutti i tag "tecnologici" corrispondenti. In base a come la classe XMLREADER funziona in C #, è possibile ottenere un vantaggio di prestazioni significativo rispetto all'altro (tutte le altre variabili sono uguali)?

c# performance xml

posta BenW301 04.04.2015 - 21:30

fonte

2 risposte

0

Per migliorare le prestazioni e simulare più nodi indipendentemente dalle dimensioni XML, è possibile utilizzare XSLT con XML e quindi utilizzare xpath per recuperare i nodi. Questo sarebbe molto meglio.

risposta data 05.04.2015 - 04:10

fonte

Leggi altre domande sui tag c# performance xml

Come iniettare il componente verificabile dall'unità nella classe verificabile dall'unità? Per convertire in tipi di dati accurati o mantenere il tipo di stringa predefinito

score 5 · Accepted Answer

Nel primo caso, dovrai creare una ricerca o scorrere i tag per trovare un tag specifico. Nel secondo caso, .NET Framework lo fa per te durante l'elaborazione del file XML.

Ad esempio, se vuoi trovare più volte (e per multipli, intendo molto ) se un requisito ha un tag specifico, il secondo caso sarà semplice; il primo richiederà lavoro aggiuntivo per la creazione della ricerca, in primo luogo.

Ovviamente, la differenza di prestazioni inizierà a essere evidente quando lavori con centinaia di migliaia di requisiti, contenenti ogni centinaia di migliaia di tag . A questa scala, sarete in grado di implementare entrambe le soluzioni, fare i benchmark e determinare quale sia più veloce, eventualmente profilare entrambi e rimuovere i colli di bottiglia prima di scegliere quello che volete mantenere.

Fino ad allora, ciò che stai facendo è ottimizzazione prematura . Sulla base di asserzioni speculative, probabilmente finirai per scrivere più codice e renderlo difficile da leggere e mantenere, in nome di alcuni microsecondi di runtime salvati (ma mai effettivamente misurati).

I motivi per scegliere la struttura XML di solito si basano su quanto bene questa struttura rappresenta i dati. Nel tuo caso, entrambi sono abbastanza rappresentativi, poiché in entrambi i casi, comprendiamo bene che un requisito contiene i tag tecnologia e utenti . Per quanto riguarda gli strumenti, la maggior parte sarà in grado di gestire entrambi allo stesso modo. Pensa all'utilizzo di XSLT per ottenere un elenco di tag o CSS per creare tag in una pagina: puoi farlo in entrambi i casi facilmente.

Un vantaggio del primo approccio può essere quando viene utilizzato con lingue tipizzate staticamente. Ma anche in questo caso, la maggior parte dei framework ti consente di manipolare la seconda struttura senza dover utilizzare Reflection.