Bug 1667696 - Use standard rust channels on Windows. r=jrmuizel

While we measuered somewhat surprisingly high performance improvements on linux when replacing standard channels with crossbeam ones on Linux, there has been a CONTENT_FRAME_TIME regression on Windows around the same time. In doubt, this patch makes us use standard channels on Windows to see if it fixes the regression. This patch will be reverted if it doesn't turn out restore the CONTENT_FRAME_TIME numbers.

Swgl needs to continue using crossbeam because it depends on select which doesn't exist in standard channels.

Differential Revision: https://phabricator.services.mozilla.com/D92383
This commit is contained in:
Nicolas Silva 2020-10-05 14:01:08 +00:00
Родитель bd5cfda423
Коммит 1db54669eb
3 изменённых файлов: 36 добавлений и 10 удалений

Просмотреть файл

@ -573,7 +573,7 @@ impl SwCompositeGraphNode {
/// After processing a band, check all child dependencies and remove this parent from
/// their dependency counts. If applicable, queue the new child bands for composition.
fn unblock_children(&self, sender: &channel::Sender<Arc<SwCompositeGraphNode>>) {
fn unblock_children(&self, sender: &channel::crossbeam::Sender<Arc<SwCompositeGraphNode>>) {
if self.num_bands.fetch_sub(1, Ordering::SeqCst) > 1 {
return;
}
@ -597,12 +597,12 @@ impl SwCompositeGraphNode {
/// the job count.
struct SwCompositeThread {
/// Queue of available composite jobs
job_sender: channel::Sender<Arc<SwCompositeGraphNode>>,
job_receiver: channel::Receiver<Arc<SwCompositeGraphNode>>,
job_sender: channel::crossbeam::Sender<Arc<SwCompositeGraphNode>>,
job_receiver: channel::crossbeam::Receiver<Arc<SwCompositeGraphNode>>,
/// Count of unprocessed jobs still in the queue
job_count: AtomicUsize,
/// Condition signaled when there are no more jobs left to process.
jobs_completed: channel::Receiver<()>,
jobs_completed: channel::crossbeam::Receiver<()>,
}
/// The SwCompositeThread struct is shared between the SwComposite thread
@ -613,8 +613,8 @@ impl SwCompositeThread {
/// Create the SwComposite thread. Requires a SWGL context in which
/// to do the composition.
fn new() -> Arc<SwCompositeThread> {
let (job_sender, job_receiver) = channel::unbounded_channel();
let (notify_completed, jobs_completed) = channel::fast_channel(1);
let (job_sender, job_receiver) = channel::crossbeam::unbounded();
let (notify_completed, jobs_completed) = channel::crossbeam::bounded(1);
let info = Arc::new(SwCompositeThread {
job_sender,
job_receiver,
@ -717,7 +717,7 @@ impl SwCompositeThread {
}
// Otherwise, there are remaining jobs that we need to wait for.
loop {
channel::select! {
channel::crossbeam::select! {
// Steal jobs from the SwComposite thread if it is busy.
recv(self.job_receiver) -> graph_node => if let Ok(graph_node) = graph_node {
if self.process_job(graph_node) {

Просмотреть файл

@ -3,7 +3,7 @@
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
use api::units::DeviceIntSize;
use api::crossbeam_channel::{bounded, Sender, Receiver};
use api::channel::{fast_channel, Sender, Receiver};
use api::DebugFlags;
use crate::render_api::{ApiMsg, DebugCommand};
use crate::print_tree::PrintTreePrinter;
@ -111,7 +111,7 @@ pub struct DebugServerImpl {
impl DebugServerImpl {
pub fn new(api_tx: Sender<ApiMsg>) -> DebugServerImpl {
let (debug_tx, debug_rx) = bounded(64);
let (debug_tx, debug_rx) = fast_channel(64);
let socket = ws::Builder::new()
.build(move |out| {

Просмотреть файл

@ -7,7 +7,14 @@ use byteorder::{LittleEndian, ReadBytesExt, WriteBytesExt};
use serde::{Deserialize, Deserializer, Serialize, Serializer};
use std::io::{self, Cursor, Error, ErrorKind, Read};
use std::mem;
pub use crossbeam_channel::{select, Sender, Receiver};
pub use crossbeam_channel as crossbeam;
#[cfg(not(target_os = "windows"))]
pub use crossbeam_channel::{Sender, Receiver};
#[cfg(target_os = "windows")]
pub use std::sync::mpsc::{Sender, Receiver};
#[derive(Clone)]
pub struct Payload {
@ -132,6 +139,7 @@ impl<'de, T> Deserialize<'de> for MsgSender<T> {
/// A create a channel intended for one-shot uses, for example the channels
/// created to block on a synchronous query and then discarded,
#[cfg(not(target_os = "windows"))]
pub fn single_msg_channel<T>() -> (Sender<T>, Receiver<T>) {
crossbeam_channel::bounded(1)
}
@ -144,6 +152,7 @@ pub fn single_msg_channel<T>() -> (Sender<T>, Receiver<T>) {
/// - high enough to avoid blocking on the common cases,
/// - or, on the contrary, using the blocking behavior as a means to prevent
/// fast producers from building up work faster than it is consumed.
#[cfg(not(target_os = "windows"))]
pub fn fast_channel<T>(capacity: usize) -> (Sender<T>, Receiver<T>) {
crossbeam_channel::bounded(capacity)
}
@ -151,4 +160,21 @@ pub fn fast_channel<T>(capacity: usize) -> (Sender<T>, Receiver<T>) {
/// Creates an MPMC channel that is a bit slower than the fast_channel but doesn't
/// have a limit on the number of messages held at a given time and therefore
/// doesn't block when sending.
#[cfg(not(target_os = "windows"))]
pub use crossbeam_channel::unbounded as unbounded_channel;
#[cfg(target_os = "windows")]
pub fn fast_channel<T>(_cap: usize) -> (Sender<T>, Receiver<T>) {
std::sync::mpsc::channel()
}
#[cfg(target_os = "windows")]
pub fn unbounded_channel<T>() -> (Sender<T>, Receiver<T>) {
std::sync::mpsc::channel()
}
#[cfg(target_os = "windows")]
pub fn single_msg_channel<T>() -> (Sender<T>, Receiver<T>) {
std::sync::mpsc::channel()
}