In addition to the issues described earlier, I filed a bug in parallel
about kicad freezing after closing pcbnew where fpinfo-cache writing to
network locations would take 10s (not a network speed issue).
https://bugs.launchpad.net/kicad/+bug/1838209
Global cache should not be written everytime pc
On 2019-07-24 13:58, Andy Peters wrote:
On Jul 23, 2019, at 2:46 PM, Jeff Young wrote:
Hi Kevin,
No this is just a cache of footprint library properties so that we can
index and search footprints without loading them all into memory.
It’s entirely for performance.
User question:
Should t
> On Jul 23, 2019, at 2:46 PM, Jeff Young wrote:
>
> Hi Kevin,
>
> No this is just a cache of footprint library properties so that we can index
> and search footprints without loading them all into memory. It’s entirely
> for performance.
User question:
Should the project-level cache file
Hi Kevin,
No this is just a cache of footprint library properties so that we can index
and search footprints without loading them all into memory. It’s entirely for
performance.
Cheers,
Jeff.
> On 23 Jul 2019, at 15:35, Kevin Cozens wrote:
>
> On 2019-07-23 11:47 a.m., Seth Hillbrand wrote
On 2019-07-23 11:47 a.m., Seth Hillbrand wrote:
Could we write the global cache in the user's config directory next to where
we write fp-lib-table?
If we cache global, we might not need project-based caching.
I'm not clear whether you are talking about caches of what items are
available or a
On 7/23/19 2:28 PM, jp charras wrote:
> Le 23/07/2019 à 20:09, Seth Hillbrand a écrit :
>> On 2019-07-23 13:38, jp charras wrote:
>>> Le 23/07/2019 à 19:22, Jeff Young a écrit :
Hi Seth,
I think that would work. And you’re right — there probably aren’t
enough project libs to re
And come to think of it, there is Murphy’s Law:
The best way to ensure that someone out there has hundreds of local libs is to
get rid of the local-lib-cache.
Cheers,
Jeff.
> On 23 Jul 2019, at 12:28, jp charras wrote:
>
> Le 23/07/2019 à 20:09, Seth Hillbrand a écrit :
>> On 2019-07-23 13:3
Le 23/07/2019 à 20:09, Seth Hillbrand a écrit :
> On 2019-07-23 13:38, jp charras wrote:
>> Le 23/07/2019 à 19:22, Jeff Young a écrit :
>>> Hi Seth,
>>>
>>> I think that would work. And you’re right — there probably aren’t
>>> enough project libs to require a cache for them.
>>
>> I am not sure to
On 2019-07-23 13:38, jp charras wrote:
Le 23/07/2019 à 19:22, Jeff Young a écrit :
Hi Seth,
I think that would work. And you’re right — there probably aren’t
enough project libs to require a cache for them.
I am not sure to understand.
The cache is by lib table, or by library file?
This is
Le 23/07/2019 à 19:22, Jeff Young a écrit :
> Hi Seth,
>
> I think that would work. And you’re right — there probably aren’t enough
> project libs to require a cache for them.
I am not sure to understand.
The cache is by lib table, or by library file?
This is very different: if it is by lib ta
No worries, I got this one.
-S
On 2019-07-23 13:22, Jeff Young wrote:
Hi Seth,
I think that would work. And you’re right — there probably aren’t
enough project libs to require a cache for them.
I’m knee-deep in the router right now, though, so someone else would
have to do it.
Cheers,
Jeff.
Hi Seth,
I think that would work. And you’re right — there probably aren’t enough
project libs to require a cache for them.
I’m knee-deep in the router right now, though, so someone else would have to do
it.
Cheers,
Jeff.
> On 23 Jul 2019, at 09:47, Seth Hillbrand wrote:
>
> Could we writ
Could we write the global cache in the user's config directory next to
where we write fp-lib-table?
If we cache global, we might not need project-based caching.
-Seth
On 2019-07-23 11:39, Jeff Young wrote:
Hi Rene,
Separate global and local caches would certainly be a refinement.
It’s not f
Hi Rene,
Separate global and local caches would certainly be a refinement.
It’s not free, though, as platforms differ on where an appropriate place to
write a global cache is. And the code has to be able to combine the two (that
might be easy or it might not — it’s been too long since I’ve bee
Is there a reason why this file is even part of the project directory? I
kind of assume it holds the info of all footprints. (If i am misinformed
about that then ignore my inquiry.) Meaning for most users will most
likely be mostly system libs that can easily change while one does not
work on t
Hi Seth,
Just performance. IIRC MSW was the real laggard, but even my Mac was more like
7 seconds to 2.
Cheers,
Jeff.
> On 22 Jul 2019, at 17:03, Seth Hillbrand wrote:
>
> Hi Folks,
>
> Odd question here but why do we have fp-info-cache? Was there a bug report
> for these or just speed im
Hi Folks,
Odd question here but why do we have fp-info-cache? Was there a bug
report for these or just speed improvements?
On my system, it is the difference between 1 second vs. 3 seconds during
the first footprint list load (full standard + personal libraries).
Does it make a bigger diff
17 matches
Mail list logo