mmh, hashing is a pretty nice technique... I remember back in the days of quake1, two simple additions were done to ID's quake-C compiler... first strcmp was replaced with a macro that started by checking the first byte of the strings before doing a full strcmp - that already gave a nice speed improvements. After that, somebody added hashing, and compiling the standard game source was suddenly 12x faster on my 486 :).

Nice to hear that the main file is only opened once - I wouldn't have expected privalov to be sloppy enough to open the main file multiple times ;). What's the reason for reopening at every FILE statement, though?
Posted on 2003-11-27 08:14:20 by f0dder

What's the reason for reopening at every FILE statement, though?


It is because the place in binary file where "file" directive places data may vary between passes. It is very complex (and probably slower) to calculate and to move the data here and there. Also, when FASM opens the same files again and again, OS cashing mechanism works good and makes compilation fasm enough. In the case with Fresh, this can't work, because some files are in the memory, some are in the disk files.

Regards.
Posted on 2003-11-27 08:33:33 by JohnFound
wouldn't it be an idea to get FILE filesize at first pass, reserve this much memory, and only read the contents on the last pass?
Posted on 2003-11-27 08:35:57 by f0dder

wouldn't it be an idea to get FILE filesize at first pass, reserve this much memory, and only read the contents on the last pass?


Unfortunately this will break portability of the FASM, if it is part of the compiler core. I make the same thing, but as part of OS interface, the core remains unchanged, because I want to implement easy in Fresh the future versions of FASM.
Posted on 2003-11-27 09:02:38 by JohnFound
Break portability? I don't really see why? Of course if somebody did this change, it should be merged back with the official fasm release - unless it break something or has disadvantages I haven't though of, of course.
Posted on 2003-11-27 09:07:01 by f0dder
This much more complex problem. Consider the following code:


if $ and 11b = 0
file '1.dat':$
else
file '2.dat':$ and 11b
end if

Now it can change between the passes what file has to be loaded, and from what position (that is: how many bytes from it). That's why very early versions of fasm were just opening and loading the file at every pass. Later I have fixed it to not load the contents of file when assembler already knows there will be at least on more pass done. With this trick fasm usually avoid reading file contents multiple times, but it also can't be sure - as the decision to make one more pass can be made later during the same pass (fortunately the resource section is usually put at the end of file, in case of such use of "file" directive contents of file is read only at last pass). But fasm still opens file every time just to get the size of file and determine how much of memory should be reserved in this part of code (and how will it affect the following labels in code). Maybe it could be avoided with creating some additional data structure containing the file names with their sizes, but actually I have never found it worth such an effort.
Posted on 2003-11-27 09:59:24 by Tomasz Grysztar
ah, I see - makes sense. Sounds like a resonable solution, too. Sure, you could make a "file-size cache", but as long as you're only opening the file to get file size, I don't think this is too important - except perhaps under dos without a disk cache :)
Posted on 2003-11-27 10:08:01 by f0dder
 


int nSize = 128;
char lpFilename[128];
GetModuleFileName(
GetModuleHandle(NULL),
lpFilename,
nSize
);


you got ful path with file.xxx: c:\sadfsdf\dss\sd\file.xx



strcpy(lpFilename, strrchr(lpFilename));


this above cut path and only file.xxx appears
Posted on 2003-11-28 02:52:13 by HarryTuttle

Hi all.
What you mean, what is the most proper (and fast) way to check whether two different strings with filenames, points to the one file?

For example - very slow solution is to call GetFullPathName for both strings and to compare results.

Regards.


How often do you need to do this? Is performance really a problem?
Cheers,
Randy Hyde
Posted on 2003-12-02 12:32:31 by rhyde
well, why wait 5 seconds 1000 times a day, while something can be done to optimize it to 2 seconds 1000 times a day :)
Posted on 2003-12-02 12:37:49 by Ultrano
I think this code will solve the problem in all sane cases. Having folders with ~ and digit after it will make problems, but who would have such a folder anyway? So, the code will work ok. There are things that need to be added (easy ones), and I don't code natively in nasm/fasm.
Posted on 2003-12-02 16:27:18 by Ultrano