Verifikationer-listan seg [LÖST]

#1

Jag har märkt det i tidigare versioner, hur hela appen låser sig för att läsa in verifikationer men i version 6 har det blivit extremt långsamt, det går inte att scrolla i listan innan programmet låser sig för att ladda in mer. Är ni medvetna om detta?

#2

Överhuvudtaget är appen seg och badbollen dyker ofta upp bara man switchar i menyn. Notera att jag sitter på senaste Macbook Pro Retina 2014 med 16GB RAM. Görs allt i en enda tråd?

#3

iOrdning testas på några olika maskiner, vissa snabbare och vissa långsammare än den maskin du beskriver, utan några nämnvärda prestandaproblem. Rent generellt är programmet väldigt beroende av att din bokföringsfil ligger på en snabb disk, så om du upplever att programmet är långsamt, ligger filen på hårddisken/SSD:n?

Det mesta görs i en tråd, ja. Alla UI-uppdateringar i Cocoa måste göras i huvudtråden, och eftersom vi använder Core Data + bindings går även det mesta av datahanteringen i huvudtråden.

#4

Som jag skrev har jag senaste MacBook Pro med 2,8 Ghz i7 + 16GM Ram och SSD.

Nu ska jag inte berätta för dig hur du ska göra ditt jobb men normalt separerar man UI och data i Cocoa enligt MVC-modell, i synnerhet när datamodellen kan bli stor. I mitt fall har jag 83 verifikationer vilket inte är särskilt mycket. Oavsett borde inläsning/parsning av data ske i en bakgrundstråd som sedan kallar på huvudtråden för UI-uppdatering.

Oavsett, för mig är programmet nu helt oanvändbart. Det är inte rimligt att sitta och vänta på badbollen hela tiden. Något jag kan göra?

#5

Jag har provat med många tusen verifikationer på betydligt långsammare datorer utan att det känns segt. Om du har din fil lagrad på SSD:n så är det förstås så snabbt det kan bli, och du får gärna maila över filen till info@iordning.se så får jag kika och se om det är något speciellt som ligger bakom i just ditt fall.

Vad som är normalt skiljer sig nog ganska mycket mellan iOS och OS X, i synnerhet som Bindings saknas på iOS.

#6

Cocoa Bindings är just avsett för att separera data och UI utan att behöva skriva mellanliggande kod. Både iOS och OX X har samma grundplåt. Det är mest specifika API:er som skiljer sig åt. Det är MVC som gäller där också.

Jag ska säga att jag har som praxis att varje verifikation innehåller ett scannat kvitto (oftast JPG eller PDF). Kan det vara det som segar ned på något sätt?

Å andra sidan är det just när UI:t ska uppdateras, oavsett om det är när man byter i menyn eller scrollar i en lista och listan uppdateras med ny data.

#7

Ja, om du har många bilder så gör det saker långsammare, eftersom vi sparar bokföringfilen ofta. Många sökningar vi gör i Core Data fungerar bara på det som är sparat till disk. Det är en teknisk begränsning i Core Data som kom i 10.6 och har funnits kvar sedan dess, så det är tyvärr inget som kommer att försvinna.

Tidigare hade vi bilder i separata filer och kunde därför undvika att behöva hantera bilden samtidigt som verifikationen. Dessvärre blir det stora problem med “sandboxing” att göra så (och även med Dropbox), och vi var tvungna att frångå detta till iOrdning 5.

#8

Hm… jag tyckte det var så praktiskt att kunna ha allt på ett ställe så att säga. Men måste bilddatan verkligen läsas in när man scrollar i listan? Den syns ju ändå inte innan man öppnar verifikationen.

Sedan måste grundproblemet vara ett annat då hela applikationen är seg i att byta vyer, oavsett om det är verifikationslistan eller t ex inställningarna för företaget. Det är bekymmersamt.

#9

Jag provade just nu med en Macbook Pro från mitten av 2012, som ju är långsammare än din maskin, och det går i stort sett ögonblickligt att växla vyer. Detta på en 50 MB stor fil med c:a 4000 fakturor och 10000 verifikationer.

Du får gärna maila över din bokföringsfil till info@iordning.se så kan jag se om det är långsamt med din fil även här.

#10

OK jag skickar dig filen.

#11

Jag och Erik löste problemet utanför forumet varför jag här ger förklaringen, skulle någon annan ha samma problem:

iOrdning har lite problem att hantera vissa bildformat helt rätt då det är optimerat för PDF:er. I mitt fall var min företagslogotyp dels av väldigt hög upplösning, dels i PNG-format som i arbetsminnet tog 109MB (på disk bara 143KB). Efter att jag minskat upplösningen något och konverterat till ren gråskala (min logotyp är bara svart/vit) gick allting bra igen, inga slöa menyer. Så har någon annan problemet, se över er logotyp. Erik är medveten om det och ska se sig om för en lösning i framtida uppdatering.

#12

Tack för uppdateringen! Oftast när Erik ber om bokföringsfil och fortsätter konversationen utanför forumet får vi andra inte veta om eller hur ett problem blir löst, så det här var verkligen uppskattat.