Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testcase big document #180 #194

Merged
merged 20 commits into from
Apr 8, 2018

Conversation

rototor
Copy link
Contributor

@rototor rototor commented Apr 6, 2018

Related to #180

This takes 5m 49s on my MacBook Pro 2014 to create a HTML file with 18.5 MB and a result PDF with 232 MB and 12694 pages using JDK 1.7.0_52.

Feel free to change the list directive

[#list 1..5000 as page] 

from 5000 to something smaller.

rototor added 16 commits April 6, 2018 17:13
but we dont really need to synchronized on a the XRLog class, as this only
slows everything down (especially when we are multithreaded,
as isLoggingEnabled() is called *often* in the code).
HotSpot *should* remove that anyway, but better not rely on it.
also don't need a copy of a readonly list,
if we only consume it without it.

In the "Bucket" sort we can lazy create the ArrayList.

And of course: Always use a ArrayList, because its in 99% always faster
then a LinkedList (as LinkedList don't play that well with the CPU
cache...)
the locking performed on it. The time FS was started there simply was no
StringBuilder so of course StringBuffer got used...

The HotSpot *should* always be able to remove the unneeded synchronized
on the StringBuffer, but there is no guarantee. If there is no synchronized
because of the StringBuilder it doesn't need to do anything.
multithreading here any more. This just makes everything slower.
}
}
infos.addAll(Arrays.asList(refs));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something IDEA cached ... if refs == null, the addAll would throw an NPE...

}
return list.iterator();
public java.util.Collection<PropertyDeclaration> getCascadedPropertyDeclarations() {
return cascadedProperties.values();
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This collection here is always directly consumed and iterated over. There was no sense in copying this...

[#macro h4][@hn 4][#nested][/@hn][/#macro]


[#list 1..100 as page]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

increase this count here for way more pages

</thead>

<tbody>
[#list 1..1000 as subRow]
Copy link
Contributor Author

@rototor rototor Apr 6, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This count is high at the moment, before merging this branch it should be decreased to a sensible value, as travis won't finish with such many rows...

@danfickle
Copy link
Owner

I’m going to work on style caching now. Provided there are no sibling selectors or custom nth-child I think we can do a much better job at avoiding running the cascade for every element.

@danfickle danfickle merged commit ac4954d into danfickle:open-dev-v1 Apr 8, 2018
@rototor rototor deleted the testcase_big_document branch April 8, 2018 06:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants