I'm trying to write a 3D OBJ file parser for the iPhone/iPad and am trying to figure out the absolute fastest method to do this. I'm not super familiar with c++ but have a few ideas. Some of the ideas I had on how to approach this were to read the whole file into a string then parse from there. Another idea was to read the file line by line and put it into vectors, but that sounds like it might be slower. I know there are a lot of tricks to make c++ extremely fast. Anyone want to take a stab at this? After I parse the file, I'm going to re-save it as a binary file for fast loading on subsequent startups. Thanks.
Check this source: http://code.google.com/p/iphonewavefrontloader/
It works pretty fast, so you can learn how it is implemented.
Related
I want to write a test that loads .mhtml in a .t file so I can test the embedded perl. The issue I'm having is that having loaded the source with File::Slurp, running $interp->exec($source) has HTML::Mason::Interp::load() trying to use the .mhtml as a filename which is suboptimal.
Is there are better way to this?
Hard to be much help without a lot more information - like a runnable program that exhibits the problem - but have you looked at HTML::Mason::Tests?
Oh, and don't use File::Slurp. It's very broken.
I want to preface this question by first saying I am not 100% sure this is the correct place to ask.
Basically, I want to take files with the .abf (axon binary files) extension and convert them to .atf (axon text files). I was wondering if I could simply just run a script that converts binary to text or if it would be more complicated than that.
I'm making a script that takes files with the .abf extension and feeds them into the Clampex9.2 program in order to save them as .atf files. However I feel like there is a much better way than manually feeding the files into a program, then resaving them with the correct extension.
Again, if this is not the right forum for this type of question, I apologize but thank you in advance if anyone can help me with this problem!
I need to replace a file on a zip using iOS. I tried many libraries with no results. The only one that kind of did the trick was zipzap (https://github.com/pixelglow/zipzap) but this one is no good for me, because what really do is re-zip the file again with the change and besides of this process be to slow for me, also do something that loads the whole file on memory and make my application crash.
PS: If this is not possible or way to complicated, I can settle for rename or delete an specific file.
You need to find a framework where you can modify how data is read and written. You would then use some form of mmap to essentially read and write small chunks. Searching on NSData and mmap resulted in this Post, however you can use mmap from the posix level too. Ps it will be slower than using pure memory no way around that.
Got it WORKING!! JXZip (https://github.com/JanX2/JXZip) has made exactly what I need, they link to libzip (http://www.nih.at/libzip/) that is a fully equiped library for working with ZIP files and JXZip have all the necessary Objective-C wrapper code. Thanks for all the replys.
For archive purposes, as the author of zipzap:
Actually zipzap does exactly what you want. If you replace an entry within a zip file, zipzap will do the minimum necessary to update it: it will skip writing all entries before the replaced entry, then write out the entry, then write out all entries after the replaced entry without recompressing. At the moment, it does require sufficient memory for the entries after the replaced entry though.
I want to extract all the keywords from a huge pdf file [50MB] ?
which module is good for large pdf files to parse ?
I'm concerned with memory for parsing huge file & extracting almost all the keywords !
Here i want SAX kind of parsing [one go parsing ] & not DOM kind of [ analogy to XML].
To read text out of a PDF, we use CAM::PDF, and it worked just fine. It wasn't hugely fast on some larger files, but the ability to handle large files was not bad. We certainly had a few that were ~100Mb, and which were handled OK. If I recall, we struggled with a few that were 130Mb on a 32-bit (Windows) Perl, but we had a whole lot of other stuff in memory at the time. We did look at PDF::API2, but it seemed more oriented to generating PDFs that reading from them. We didn't throw large files into PDF::API2, so I can't give a real benchmark figure.
The only significant downside we found with using CAM::PDF is that PDF 1.6 is becoming more common, and that doesn't work at all in CAM::PDF yet. That might not be an issue for you, but it might be something to consider.
In answer to your question, I'm pretty sure both modules read the whole source PDF into memory in one form or another, but I don't think CAM::PDF builds as many more complex structures out of it. So neither is really SAX-like, but CAM::PDF seemed to be lighter in general, and can retrieve one page at a time, so might reduce the load for extracting very large texts.
I am looking for the best way to read a CSV file line by line. I want to know what are the most efficient ways of doing the same. I am particulary concerned when the size of the file is big. Are the file reading utilities avilable in the .NET classes the most effient?
(PS: I have searched for the word 'Efficient' to know if someone has already posted similar question before posting this.)
You can try this: fast CSV Parser.
Here's the benchmark result:
To give more down to earth numbers,
with a 45 MB CSV file containing 145
fields and 50,000 records, the reader
was processing about 30 MB/sec. So all
in all, it took 1.5 seconds! The
machine specs were P4 3.0 GHz, 1024
MB.
The file handling in .NET is fine. If you want to read a line at a time in a comfortable way using foreach, I have a simple LineReader class you might want to look at (with a more general purpose version in MiscUtil).
With that you can use:
foreach (string line in new LineReader(file))
{
// Do the conversion or whatever
}
It's also easily usable with LINQ. You may or may not find this helpful - if the accepted solution works for you, that may be a better "off the shelf" solution.