const currentPage = dv.current().file;
const dailyPages = dv.pages('"0-Daily"').sort(k=>k.file.name, "asc");
const currentPageName = currentPage.name;
const index = dailyPages.findIndex((e) => {return e.file.name === currentPageName});
if (index < 1) {
dv.table(["File", "Created", "Size"],[]);
} else {
const lastIndex = index - 1;
const lastPage = dailyPages[lastIndex].file;
const allPages = dv.pages().values;
const searchPages = [];
const lastTime = dv.parse(lastPage.name);
const currentTime = dv.parse(currentPage.name);
for (let page of allPages) {
const pageFile = page.file;
if (pageFile.cday > lastTime && pageFile.cday <= currentTime) {
searchPages.push(pageFile);
}
}
dv.table(["File", "Created", "Size"], searchPages.sort((a, b) => a.ctime > b.ctime ? 1 : -1).map(b => [b.link, b.ctime, b.size]));
}
下载时的多线程和单线程
下载过程中用多线程是会提速的。
我们下载的速度实际就是实时抢占网络宽带的大小。实际上！！！
用户进程实时抢占的带宽 ≤实时网络可用带宽
那现在我们要做的就是无限接近实时网络可用带宽对吧？
可是！TCP有流量探测机制，一旦检测到有丢包就会减速！来个图！
很显然，指数级降速，线性增速，这很不公平！降速很快，但升速却很漫长！造成的直接恶果就是真实的传输速率远远小于实时可用带宽。 这没办法，为了避免网络拥塞对吧？这就有点牺牲小我成全大家的精神，我的减速是为了大家能用。
多线程相比单线程的优势是，由于有多个线程在竞争实时可用带宽。尽管多线程逻辑上是并行的，但其实还是按时序的串行处理。所以每个线程处于的阶段并不一致。 在任意时刻，有的线程处于丢包被罚1/2降速，有的线程处于2倍增速阶段（SlowStart），而有的线程处于线性增长阶段。通过多个线程的下载速率的加权平均，得到的是一根相对平滑的下载曲线。这条平滑曲线在大多数时候应该位于单线程下载速率的上方。这就是多线程下载速率更有优势的体现。！！！ 但是，如果TCP流量探测机制更加智能，比如BBR算法。BBR算法最大的进步，就是摒弃传统TCP流量调度算法（基于是否丢包而升速或降速）， BBR采取的是，实时测量网络最大的可用带宽，并将发送速率与之相匹配，一直在实时可用带宽附近小范围徘徊，避免大起大落的情况发生。测量速率能无限接近实时可用带宽，多线程相比单线程，优势就体现不出来了。
所以在是TCP是传统的拥塞算法的情况下，多线程还是有优势的。