2012-05-15 13 views
7

Sto lavorando a un gioco e abbiamo archiviato le informazioni sul livello in formato JSON. Questi livelli sono abbastanza grandi, così siamo passati a poco la loro memorizzazione in pianura C#:Compilatore AOT MonoTouch - Fallimento di metodi di grandi dimensioni

  • Metodo di livello superiore ha un'istruzione switch per il nome del livello/oggetto
  • Sono disponibili diversi metodi generate automaticamente che "new up" il nostro albero oggetto con inititalizers proprietà standard

Esempio:

private OurObject Autogenerated_Object1() 
{ 
    return new OurObject { Name = "Object1", X = 1, Y = 2, Width = 200, Height = 100 }; 
} 

Tranne questi metodi sono molto grandi e hanno nidificato liste/dizione ariete di altri oggetti, ecc.

Questo ha accelerato il tempo di caricamento di un livello da 2-3 secondi a frazioni di secondo (su Windows). Anche la dimensione dei nostri dati è considerevolmente più piccola, come l'IL compilato rispetto a JSON.

Il problema è quando compiliamo questi in MonoDevelop per MonoTouch, otteniamo:

mtouch exited with code 1

Con -v -v -v acceso, possiamo vedere l'errore:

MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/monotouch.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/monotouch.dll" 
AOT Compilation exited with code 134, command: 
MONO_PATH=/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --aot=mtriple=armv7-darwin,full,static,asmonly,nodebug,outfile=/var/folders/4s/lcvdj54x0g72nrsw9vzq6nm80000gn/T/tmp54777849.tmp/DrawAStickmanCore.dll.7.s "/Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll" 
Mono Ahead of Time compiler - compiling assembly /Users/jonathanpeppers/Desktop/DrawAStickman/Game/Code/iOS/DrawAStickman.iPhone/bin/iPhone/Release/DrawAStickmaniPhone.app/DrawAStickmanCore.dll 
* Assertion: should not be reached at ../../../../../mono/mono/mini/mini-arm.c:2758 

C'è un limite al numero di linee in un metodo, durante la compilazione per AOT? C'è qualche argomento che possiamo passare a mtouch per risolvere questo problema? Alcuni file funzionano bene, ma uno in particolare che causa l'errore ha un metodo di 3.000 linee. La compilazione per il simulatore funziona bene, non importa quale.

Questo è ancora un esperimento, quindi ci rendiamo conto che questa è una situazione piuttosto folle.

+0

Funziona con piccoli livelli? –

+0

Sì, funziona bene con livelli più piccoli. Non appena aggiungo un cespuglio o un albero, inizia il problema e il simulatore funziona correttamente. – jonathanpeppers

+0

Si prega di compilare un bug report :) – poupou

risposta

4

Tali affermazioni si verificano quando si verifica una condizione che dovrebbe mai verificarsi nel compilatore AOT. Si prega di segnalare tali casi alla http://bugzilla.xamarin.com

Is there some argument we can pass to mtouch to fix this?

Si potrebbe essere in grado di risolvere questo utilizzando LLVM (o non lo si utilizza), in quanto si tratta di un motore di diversa generazione del codice. A seconda di quale fase si verifica (alcuni sono condivisi) potresti non imbatterti nella stessa condizione.

Ovviamente le build LLVM sono più lente e non supportano il debug, quindi non è una soluzione ideale per ogni circostanza.

+0

Farò un progetto di esempio e segnalare il bug. Ricevo un errore simile compilando con LLVM: '* Asserzione a ../../../../../mono/mono/mini/ssa.c:243, condizione' stack_history_len jonathanpeppers

+0

Bug è qui: https://bugzilla.xamarin.com/show_bug.cgi?id = 5093 – jonathanpeppers

+0

Zoltan dice che è stato risolto, non è sicuro per quanto tempo finché non sarà nel canale alpha/beta da provare. – jonathanpeppers

1

Solo un consiglio per la conservazione dei livelli. Hai considerato di memorizzare i livelli in un formato binario molto veloce come i Protocol Buffers? .NET ha una meravigliosa libreria di buffer di protocollo chiamata Protobuf-net che potresti voler controllare.

+0

L'ho esaminato, il problema è che ho elenchi/dizionari annidati, oltre a una classe con più elenchi (matrici frastagliate) e non ha il supporto per questo. – jonathanpeppers

+0

Potrebbe essere possibile racchiudere gli array/elenchi interni come classi e serializzarli in questo modo. Ma probabilmente hai già esplorato questa opzione. – tamaslnagy

+0

MsgPack è un'altra opzione. Lo sto usando per serializzare sulla rete e, a un certo punto, potrei usarlo per sostituire Json per una serializzazione più veloce su disco. –

Problemi correlati