code: public int pathQueryLimit() {
  		/* We first compute the ratio beween the delay for scheme+authorities and the IP delay.
  		 * It is usually greater than one and it expresses the number of scheme+authorities
  		 * that can "fit" the IP delay. */
  		final double delayRatio = Math.max(1 , (frontier.rc.schemeAuthorityDelay + 1.) / (frontier.rc.ipDelay + 1.));
  		/* We now establish a scaling factor depending on the size of the workbench entry. Entries of
  		 * size less than or equal to delayRatio have scaling factor one, as there is no scheme+authority
  		 * slowdown due to the IP delay. However, entries with greater size are scaled proportionally.
  		 * For instance, if delayRatio is 4 up to 4 scheme+authorities with the same IP on average will cause
  		 * no slowdown, but if you have 8 scheme+authorities on the same IP each one will be slowed down by a factor
  		 * of two: indeed, if scheme+authorities are accessed round-robin, you will need to wait for 8 ipDelays, which
  		 * amounts to 2 scheme+authority delays. */
  		final double scalingFactor = workbenchEntry == null ? 1 : Math.max(1, workbenchEntry.size() / delayRatio);
  		/* Finally, we divide the estimated workbench size in path+queries by the size of the required front multiplied
  		 * by the scaling factor. We also maximize with 4 and minimize with the number of path+queries that
  		 * can be fetched in five minutes. */
  		return (int)Math.min(300000 / (frontier.rc.schemeAuthorityDelay + 1),
  				Math.max(4, (long)Math.ceil((frontier.workbenchSizeInPathQueries /
  						(scalingFactor * frontier.requiredFrontSize.get())))));
  	}
docs: Returns an estimate of the number of path+queries that this visit state should keep in memory.
  
  @return an estimate of the number of path+queries that this visit state should keep in memory.