Author Topic: utSeek is slow with larger files  (Read 6878 times)

Offline timadria

  • Newbie
  • *
  • Posts: 9
    • View Profile
utSeek is slow with larger files
« on: May 24, 2012, 09:42:37 AM »
Im using the SD card to store a logfile with a lot of measurements.
When I read out these measurements I do this:
  • I go to the end of the file
  • read my last measurement
  • Send this to my pc
  • delete the last measurement from the file (by changing the filesize)

The problem is that when I have a large file the utSeek will take some time because it needs to scroll trough all the sectors.

Is there a way to speed up this process?

Kind regards Tim

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: utSeek is slow with larger files
« Reply #1 on: May 24, 2012, 06:29:10 PM »
Hi Tim

I think that this problem is fundamental to the fact that files are stored in a cluster chain. That means that one doesn't know where the end of the file is (or intermediate content) without starting at the beginning (which is known from the FAT entry) and then scanning through this chain (as you know), which takes more time as the file gets longer.

The only way that I can think of accelerating this for such an application is to scan through the clusters once (maybe even using a background task as the counting of free clusters uses) and keep a backup of the cluster chain locations in RAM. Certainly keep a backup of the location of the end of the file (outside of the FAT code). The file entry, used when a file is opened and updated when the file pointer is moved, contains information about where the present file pointer is (meaning that it holds information about the physical cluster and present sectors). It would be possible to keep backups of 'intermediate' positions in the file cluster chain in a similar manner and so 'manipulate' a file entry so that you could move the pointer around the file content without having to do an actual scan of the card (which is the slow part).

This may not be trivial to actually do (code) but such a special solution for a single file may allows you to 'prime' the file pointer based on where you want to scroll back to in order to speed up the actual movement involved and so make the particular operation much faster.

Regards

Mark