Esteban, Sebastian,
In the filetree code, you will find a format without metadata, but it's
not in use anymore.
If you use gitfiletree, it will write the metadata for compatibility
reasons with filetree, but it will never read it back.
I'm pushing code to make filetree robust to absence of metadata, but I
haven't worked on it for a while.
gitfiletree has solved the problem of a slow metadata read. It does not
solve any performance problem associated with writing, yet.
Thierry
Le 11/12/2013 16:12, Esteban Lorenzano a écrit :
I know there is a version of filetree without metadata (more compelling
for projects that will never use other formats).
Dale told me that there was a preview somewhere, but I didn't tested yet
(lack of time) and now I cannot find the mail...
Dale, can you re-send the link?
cheers,
Esteban
On Wed, Dec 11, 2013 at 4:08 PM, Sebastian Sastre
<sebast...@flowingconcept.com <mailto:sebast...@flowingconcept.com>> wrote:
I should breath before I type, but you probably already got that I
meant /redundant writes/ (not reads)...
Anyway.. I was talking with Esteban and he mentions some kind of
compatibility metadata.
If I'm going to give a leap of faith to filetree repos to save code
why should I care about mcz compatibility? Paying a toll for no
reason is evil.
Maybe we could make that optional so those who don't extract value
from that feature can opt-out?
sebastian <https://about.me/sebastianconcept>
o/
On Dec 11, 2013, at 12:44 PM, Sebastian Sastre
<sebast...@flowingconcept.com <mailto:sebast...@flowingconcept.com>>
wrote:
Hi Thierry
On Dec 11, 2013, at 12:43 PM, Goubier Thierry
<thierry.goub...@cea.fr <mailto:thierry.goub...@cea.fr>> wrote:
I have packages (in the order of hundreds of classes) and save
delays
and package click delays are starting to demand patience in a
way that
doesn't feel like the right path
Which operations ? I didn't remember noticing much with 179
classes on a laptop without a SSD.
choose one. Just for clicking the package that will should you
UUID, version and author I need to wait ~16 seconds. Sounds like a
lot of overhead for reading a small .json file.
But the write is the most worrisome
All that is with a SSD disk, otherwise save delays would be
/way/ beyond
unacceptable
I'd like to know more, and understand the reason, for sure. As
far as I know, filetree will rewrite the whole package to disk
everytime... and maybe optimising that could be the solution.
Well, that explains a lot. Writing all every time is the lazy
thing that's okay for a prototype and temporary code in a proof of
concept but that massive redundant reads certainly doesn't sounds
like pro software. Specially for SSD's which has a limited
quantity of writes
Thierry
sebastian <https://about.me/sebastianconcept>
o/
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92
<tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95
--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
