Pour le traitement du journal, mon application doit lire la ligne de fichiers texte par ligne.
J'ai d'abord utilisé la fonction readline () de bufferedreader mais j'ai lu sur Internet que Bufferedreader est lent lors de la lecture de fichiers.
Ensuite, j'ai essayé d'utiliser FileInputStream ensemble avec un fichier filechannel et mappébytebuffer, mais dans ce cas, il n'y a pas de fonction similaire à readline () alors je recherche mon texte pour une pause de ligne et processus:
try {
FileInputStream f = new FileInputStream(file);
FileChannel ch = f.getChannel( );
MappedByteBuffer mb = ch.map(FileChannel.MapMode.READ_ONLY, 0L, ch.size());
byte[] bytes = new byte[1024];
int i = 0;
while (mb.hasRemaining()) {
byte get = mb.get();
if(get == '\n') {
if(ra.run(new String(bytes)))
cnt++;
for(int j = 0; j<=i; j++)
bytes[j] = 0;
i = 0;
}
else
bytes[i++] = get;
}
} catch(Exception ex) {
ex.printStackTrace();
}
5 Réponses :
Je doute vivement que Par exemple, dans le code que vous avez donné que vous appelez Avez-vous réellement essayé en utilisant Autre alternative, vous voudrez peut-être regarder surcharge de GUAVA de bufferedreader va causer une surcharge importante. L'ajout de votre propre code est susceptible d'être au moins aussi inefficace et probablement également.
nouvelle chaîne (octets) qui va toujours créer une chaîne à partir de 1024 octets, à l'aide du codage par défaut de la plate-forme ... pas une bonne idée. Bien sûr, vous effacez le tableau après, mais vos chaînes vont toujours contenir un tas de personnages «\ 0» - ce qui signifie beaucoup d'espace gaspillé, en dehors de toute autre chose. Vous devriez au moins restreindre la partie du groupe d'octets que la chaîne est en cours de création (qui signifie également que vous n'avez pas besoin d'effacer le tableau après).
bufferedreader et l'a trouvé trop lent? Vous devriez généralement écrire le code le plus simple qui répondra en premier à vos objectifs, puis vérifiez si c'est assez rapide ... surtout si votre seule raison de ne pas le faire est une ressource non spécifiée que vous «lisez sur Internet». Voulez-vous que je trouve des centaines d'exemples de personnes jaillissent des suggestions de performance incorrectes? :)
fichiers.readlines () qui prend un LineProcessor .
J'ai essayé Bufferedreader et cela fait du bien, mais l'exigence du programme est d'être vraiment rapide, alors j'essaie simplement de déterminer quelle solution est le meilleur le plus rapide pour ma mise en œuvre.
@Yoni: "vraiment rapide" est une exigence assez vague. Avez-vous même des preuves que c'est bufferedreader qui est le goulot d'étranglement plutôt que (beaucoup plus probable) la vitesse du disque physique?
Si je lisais les mêmes fichiers en octets, il est 3 fois plus rapide, puis en utilisant bufferedreader . Ma vitesse de disque dur est d'environ 150 Mo / s tandis que mon programme se lit à 30 Mo / s.
@Yoni: Hmm ... c'est un peu surprenant. Quel codage utilisez-vous et quelle est votre machine Spec? Est-ce que vous courez dans le débogueur ou faisez-vous autre chose qui pourrait le ralencer? Êtes-vous en utilisant les cordes du tout?
J'utilise le codage Windows-1258 car les fichiers contiennent des caractères vietnamiens. J'utilise les cordes pour trouver un motif de regex. Ils sont donnés à l'instance Runautomaton. Ma machine Spécifications: C2D P8700, 4GB DDR2, HD: 500 Go (SATA2) 7200RPM. Je ne cours pas dans le débogueur et ce n'est pas dû à la regex qu'il est lent, car lorsque vous commencez à commenter le runautomaton, la lecture est à la même vitesse.
On dirait que la seule solution appropriée consiste à utiliser une bufferedReader. Parce que vous avez donné les informations les plus utiles et complètes que j'accepte votre réponse.
@Yoni: C'est très étrange que le regex ne soit pas d'impact ... Une chose à garder à l'esprit est que pour des raisons étranges, spécifiant un Charset est plus lent que la spécification du nom I> d'un codage, de sorte que cela pourrait vous aider.
UTILISATION D'UTILISER BUFFERDREADER J'ai eu plus plus que plus de MB / s . Il est fort probable que la vitesse que vous puissiez lire les données du disque est votre goulot de bouteille, alors comment vous faites la lecture ne fera pas beaucoup de différence.
bufferedreader n'est pas la seule solution, mais il est assez rapide pour 99% des cas d'utilisation, alors pourquoi rendre les choses plus compliquées qu'elles doivent être?
sont des cadres une alternative?
Je ne sais pas sur la performance, mais
http://commons.apache.org/io/api-relase/ Index.html Voir la classe IOUTILS
Définit très facile à utiliser des classes d'assistance pour de tels cas.
J'ai une boucle très simple qui lit environ 2000 lignes (50k bytes) à partir d'un fichier sur la carte SDCard à l'aide de bufferedreader et il les lit à environ 100 ms dans le mode de débogage sur l'onglet Galaxy 2. Pas trop mal. Ensuite, j'ai mis un scanner dans la boucle et le temps passé à travers le toit (dizaines de secondes), plus de nombreux messages GC_Conçurants donc au moins dans mon cas c'est le scanner qui est le problème, Je suppose que j'ai besoin de numériser l'intégralité d'une autre manière, mais je ne sais pas pourquoi cela pourrait être si lent
BufferDreader est-il vraiment trop lent pour vos besoins? C'est probablement l'une des solutions les plus propres et les plus maintenues si vous devez coder en Java.
Si
bufferedreader est vraiment trop lent pour votre application, vous devez penser à ne pas utiliser Java ou d'autres langues gérées ... (mais je doute que c'est le cas)La réponse d'Aaron est sur le point d'être supprimée comme une réponse de lien unique, je vais donc la mettre ici comme un commentaire: "Vérifiez Ce lien out. Il contient une comparaison de vitesse de différentes méthodes."